From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [Xen-users] FreeBSD PVHVM call for testing Date: Wed, 29 May 2013 14:24:44 -0400 Message-ID: <20130529182444.GC10845@phenom.dumpdata.com> References: <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> <51A634EC.7050805@citrix.com> <1369848356.22605.51.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1369848356.22605.51.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel , Matt Wilson , Roger Pau =?iso-8859-1?Q?Monn=E9?= List-Id: xen-devel@lists.xenproject.org On Wed, May 29, 2013 at 06:25:56PM +0100, Ian Campbell wrote: > (dropping the BSD lists & xen-users, adding Konrad) > = > On Wed, 2013-05-29 at 19:03 +0200, Roger Pau Monn=E9 wrote: > > 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 !=3D acpi_id: > > = > > http://xenbits.xen.org/gitweb/?p=3Dpeople/royger/freebsd.git;a=3Dshortl= og;h=3Drefs/heads/pvhvm_v12 > > = > > Since I'm not able to reproduce the cpuid !=3D acpi_id case, could you > > give it a try and report the results? > = > Konrad, > = > Might this same problem be related to the issue you saw doing PVHVM VCPU > hotplug which you mentioned the other day? This was http://article.gmane.org/gmane.comp.emulators.xen.devel/159105 > = > In general for HVM I suppose there isn't a strict relationship between > the CPU number the kernel chooses for a CPU (which is somewhat > arbitrarily up to the kernel) and the hypervisors VCPU number (which is > exposed via the virtual APIC ID). Right. To troubleshoot this I added some instrumentation to make sure that the xen_vcpuop_set_mode function was using the right vCPU number. Initially it got it from smp_processor_id(), which gets it from the APIC ID (at least that is what it looks like). But perhaps it was not. I can't seem to reproduce the issue anymore :-(