From owner-freebsd-virtualization@FreeBSD.ORG Wed May 29 17:03:50 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A71A046B; Wed, 29 May 2013 17:03:50 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) by mx1.freebsd.org (Postfix) with ESMTP id EF79F9F8; Wed, 29 May 2013 17:03:49 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,765,1363132800"; d="scan'208";a="5104336" Received: from lonpex01cl01.citrite.net ([10.30.203.101]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 29 May 2013 17:03:42 +0000 Received: from [192.168.1.30] (10.30.203.1) by LONPEX01CL01.citrite.net (10.30.203.101) with Microsoft SMTP Server id 14.2.342.3; Wed, 29 May 2013 18:03:41 +0100 Message-ID: <51A634EC.7050805@citrix.com> Date: Wed, 29 May 2013 19:03:40 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Percival Subject: Re: [Xen-devel] FreeBSD PVHVM call for testing References: <51957D42.9060801@citrix.com> <51959ED9.6040405@freebsd.org> <51974EC9.9030204@citrix.com> <5197A1EA.2040404@freebsd.org> <519CAFC7.1070908@citrix.com> <519D24A9.3050407@freebsd.org> <519DDC0A.9000201@citrix.com> <519E6958.6020606@freebsd.org> <519F3CD0.5090405@citrix.com> <51A4D804.9050208@citrix.com> <20130528191855.GA13736@u109add4315675089e695.ant.amazon.com> <51A5229F.80205@freebsd.org> In-Reply-To: <51A5229F.80205@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.30.203.1] Cc: "freebsd-xen@freebsd.org" , xen-devel , "freebsd-virtualization@freebsd.org" , Matt Wilson , "xen-users@lists.xen.org" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:03:50 -0000 On 28/05/13 23:33, Colin Percival wrote: > On 05/28/13 12:18, Matt Wilson wrote: >> VCPUOP_set_singleshot_timer returns -EINVAL when: >> >> 1) the specified vCPU ID is out of range (<0 or >MAX_VIRT_CPUS) >> 2) the specified vCPU ID doesn't match the running vCPU. >> >> It seems that there is a confusion between the logical vCPU ID and the >> local APIC physical ID. >> [...] >> (XEN) Domain 1 (vcpu#16) VCPUOP_set_singleshot_timer specified vcpuid 1 >> [...] >> APIC: CPU 1 has ACPI ID 16 > > Thanks Matt! Looks like we need to pass our acpi_id to the Xen hypercall > instead of our cpuid. > > Roger, changing the line > int cpu = PCPU_GET(cpuid); > to > int cpu = PCPU_GET(acpi_id); > in xentimer_et_start and xentimer_et_stop fixes this panic and gets me > slightly further; the following lines are now added to the console output > prior to the system appearing to hang: >> ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 >> ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 2 vector 48 >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 >> ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 4 vector 48 >> ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 5 vector 48 >> ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 6 vector 48 >> ioapic0: routing intpin 28 (PCI IRQ 28) to lapic 7 vector 48 >> TSC timecounter discards lower 1 bit(s) >> Timecounter "TSC-low" frequency 1300024860 Hz quality -100 >> WARNING: WITNESS option enabled, expect reduced performance. Hello, Thanks Matt and Colin for the testing and help! I've pushed yet another version, now it's branch pvhvm_v12, which I *think* should solve the issues with cpuid != acpi_id: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v12 Since I'm not able to reproduce the cpuid != acpi_id case, could you give it a try and report the results? > On a cc2.8xlarge EC2 instance, the lines which come after this are >> GEOM: new disk xbd1 >> GEOM: new disk xbd2 >> GEOM: new disk xbd3 >> GEOM: new disk xbd4 >> Trying to mount root from ufs:/dev/ad0a [rw]... >> start_init: trying /sbin/init > and then the userland boot process; have you made any bug fixes after > your pvhvm_v7 which would explain why tasting disks was hanging? I'm not sure I follow, did you found a regression from previous branches? i.e. it used to work with branch pvhvm_v6 and not pvhvm_v7?