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?

_______________________________________________
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"

Reply via email to