Re: [Xen-devel] FreeBSD PVHVM call for testing

2013-05-29 Thread Matt Wilson 
On Wed, May 29, 2013 at 01:58:59PM -0700, Colin Percival wrote:
> On 29/05/13 19:22, Matt Wilson wrote:
> > Colin, can you build an AMI with this new kernel?
> 
> Done, ami-95177dfc in us-east-1.
> 
> This is now booting successfully on cr1.8xlarge; are there any other instance
> types I should test?  I don't know which Xen versions you have deployed across
> the entire fleet.

Nice! The other interesting instance types for problems like this are
cc1.4xlarge, cg1.4xlarge and cc2.8xlarge.

--msw
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: [Xen-devel] FreeBSD PVHVM call for testing

2013-05-29 Thread Matt Wilson 
On Wed, May 29, 2013 at 07:03:40PM +0200, Roger Pau Monné wrote:
> 
> 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?

Colin, can you build an AMI with this new kernel?
 
[...]

> On 28/05/13 23:33, Colin Percival wrote:
> > 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?

Colin was saying that his local change only moved the boot process a
bit farther for cr1.8xlarge. Perhaps some of the other changes you
made in the latest pvhvm_v12 branch will get the VM all the way up.

--msw
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: [Xen-devel] FreeBSD PVHVM call for testing

2013-05-28 Thread Matt Wilson 
On Tue, May 28, 2013 at 06:15:00PM +0200, Roger Pau Monné wrote:
> On 24/05/13 12:11, Roger Pau Monné wrote:
> > 
> > Thanks for the test, this is what I expected. I'm a little bit out of
> > ideas since I'm not able to reproduce this on upstream Xen 4.2. Without
> > knowing what's happening inside the hypervisor it's hard to tell what's
> > wrong. It would be interesting to try if the same happens with a Linux
> > PVHVM (not PV) running on the same instance type.
> 
> Hello Matt,
> 
> Colin has found an issue on the FreeBSD PVHVM port that I haven't been
> able to reproduce using open source Xen, even when using the same
> version as the one reported by EC2. Is there anyway you could provide
> some help debugging this? Without seeing the Xen code that causes
> VCPUOP_set_singleshot_timer to return EINVAL it is quite hard to figure
> out what's happening inside the hypervisor.

Hi Roger,

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.

I added some debugging to case 2):

diff --git a/xen/common/domain.c b/xen/common/domain.c
index e728819..e3efb8c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -901,7 +901,12 @@ long do_vcpu_op(int cmd, int vcpuid, 
XEN_GUEST_HANDLE(void) arg)
 struct vcpu_set_singleshot_timer set;
 
 if ( v != current )
+{
+printk("Domain %d (vcpu#%d) VCPUOP_set_singleshot_timer specified 
vcpuid %d\n",
+   d->domain_id, current->vcpu_id, vcpuid);
+
 return -EINVAL;
+}
 
 if ( copy_from_guest(&set, arg, 1) )
 return -EFAULT;


The output from booting ami-e75c358e on a cr1.8xlarge:

(XEN) Domain 1 (vcpu#16) VCPUOP_set_singleshot_timer specified vcpuid 1
(XEN) Domain 1 (vcpu#7) VCPUOP_set_singleshot_timer specified vcpuid 14
(XEN) Domain 1 (vcpu#23) VCPUOP_set_singleshot_timer specified vcpuid 15
(XEN) Domain 1 (vcpu#11) VCPUOP_set_singleshot_timer specified vcpuid 22
(XEN) Domain 1 (vcpu#27) VCPUOP_set_singleshot_timer specified vcpuid 23
(XEN) Domain 1 (vcpu#18) VCPUOP_set_singleshot_timer specified vcpuid 5
(XEN) Domain 1 (vcpu#2) VCPUOP_set_singleshot_timer specified vcpuid 4
(XEN) Domain 1 (vcpu#9) VCPUOP_set_singleshot_timer specified vcpuid 18
(XEN) Domain 1 (vcpu#25) VCPUOP_set_singleshot_timer specified vcpuid 19
(XEN) Domain 1 (vcpu#1) VCPUOP_set_singleshot_timer specified vcpuid 2
(XEN) Domain 1 (vcpu#6) VCPUOP_set_singleshot_timer specified vcpuid 12
(XEN) Domain 1 (vcpu#22) VCPUOP_set_singleshot_timer specified vcpuid 13
(XEN) Domain 1 (vcpu#26) VCPUOP_set_singleshot_timer specified vcpuid 21
(XEN) Domain 1 (vcpu#10) VCPUOP_set_singleshot_timer specified vcpuid 20
(XEN) Domain 1 (vcpu#14) VCPUOP_set_singleshot_timer specified vcpuid 28
(XEN) Domain 1 (vcpu#30) VCPUOP_set_singleshot_timer specified vcpuid 29
(XEN) Domain 1 (vcpu#3) VCPUOP_set_singleshot_timer specified vcpuid 6
(XEN) Domain 1 (vcpu#19) VCPUOP_set_singleshot_timer specified vcpuid 7
(XEN) Domain 1 (vcpu#12) VCPUOP_set_singleshot_timer specified vcpuid 24
(XEN) Domain 1 (vcpu#28) VCPUOP_set_singleshot_timer specified vcpuid 25
(XEN) Domain 1 (vcpu#5) VCPUOP_set_singleshot_timer specified vcpuid 10
(XEN) Domain 1 (vcpu#21) VCPUOP_set_singleshot_timer specified vcpuid 11
(XEN) Domain 1 (vcpu#24) VCPUOP_set_singleshot_timer specified vcpuid 17
(XEN) Domain 1 (vcpu#8) VCPUOP_set_singleshot_timer specified vcpuid 16
(XEN) Domain 1 (vcpu#17) VCPUOP_set_singleshot_timer specified vcpuid 3
(XEN) Domain 1 (vcpu#20) VCPUOP_set_singleshot_timer specified vcpuid 9
(XEN) Domain 1 (vcpu#4) VCPUOP_set_singleshot_timer specified vcpuid 8
(XEN) Domain 1 (vcpu#13) VCPUOP_set_singleshot_timer specified vcpuid 26
(XEN) Domain 1 (vcpu#29) VCPUOP_set_singleshot_timer specified vcpuid 27
(XEN) Domain 1 (vcpu#15) VCPUOP_set_singleshot_timer specified vcpuid 30

Note from the FreeBSD boot output:
APIC: CPU 0 has ACPI ID 0
APIC: CPU 1 has ACPI ID 16
APIC: CPU 2 has ACPI ID 1
APIC: CPU 3 has ACPI ID 17
APIC: CPU 4 has ACPI ID 2
APIC: CPU 5 has ACPI ID 18
APIC: CPU 6 has ACPI ID 3
APIC: CPU 7 has ACPI ID 19
APIC: CPU 8 has ACPI ID 4
APIC: CPU 9 has ACPI ID 20
APIC: CPU 10 has ACPI ID 5
APIC: CPU 11 has ACPI ID 21
APIC: CPU 12 has ACPI ID 6
APIC: CPU 13 has ACPI ID 22
APIC: CPU 14 has ACPI ID 7
APIC: CPU 15 has ACPI ID 23
APIC: CPU 16 has ACPI ID 8
APIC: CPU 17 has ACPI ID 24
APIC: CPU 18 has ACPI ID 9
APIC: CPU 19 has ACPI ID 25
APIC: CPU 20 has ACPI ID 10
APIC: CPU 21 has ACPI ID 26
APIC: CPU 22 has ACPI ID 11
APIC: CPU 23 has ACPI ID 27
APIC: CPU 24 has ACPI ID 12
APIC: CPU 25 has ACPI ID 28
APIC: CPU 26 has ACPI ID 13
APIC: CPU 27 has ACPI ID 29
APIC: CPU 28 has ACPI ID 14
APIC: CPU 29 has ACPI ID 30
APIC: CPU 30 has ACPI ID 15
APIC: CPU 31 has ACPI ID 31

--msw