Date: Tue, 07 Apr 2015 16:46:22 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <royger@FreeBSD.org> To: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= <gperez@entel.upc.edu> Cc: freebsd-xen@FreeBSD.org Subject: Re: Fwd: Re: Unable to boot with the dom0 xen kernel Message-ID: <5523EDBE.70709@FreeBSD.org> In-Reply-To: <5523D5A7.5040809@entel.upc.edu> References: <5523D56B.9040706@entel.upc.edu> <5523D5A7.5040809@entel.upc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello,
El 07/04/15 a les 15.03, Gustau Pérez ha escrit:
> Hi there,
>> can you apply the
>> following patch to the Xen source tree and recompile the Xen kernel,
>> (there's no need to recompile the tools):
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index e1c55ce..fc3c45b 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3102,8 +3102,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> if ( exit_qualification & 0x10 )
>> {
>> /* INS, OUTS */
>> - if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
>> - !handle_mmio() )
>> + if ( !handle_mmio() )
>> hvm_inject_hw_exception(TRAP_gp_fault, 0);
>> }
>> else
>>
>
> Sure. I applied the patch, recompiled the xen kernel, and copied it
> to /boot (as usual). I also raised the iommu debug level. Now the crash
> is different:
>
> http://dpaste.com/1H4XBY5
Ah, I've forgot about the ASSERT in handle_mmio. It looks like at least
one of the drivers for your hardware uses the INS or OUTS instruction
which is not yet correctly handled by PVH guests. You can try the
following patch, which removes the assert you hit before (again
this is for the Xen source tree):
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 68fb890..b2f1ce4 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -84,8 +84,6 @@ int handle_mmio(void)
struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
int rc;
- ASSERT(!is_pvh_vcpu(curr));
-
hvm_emulate_prepare(&ctxt, guest_cpu_user_regs());
rc = hvm_emulate_one(&ctxt);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e1c55ce..fc3c45b 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3102,8 +3102,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
if ( exit_qualification & 0x10 )
{
/* INS, OUTS */
- if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
- !handle_mmio() )
+ if ( !handle_mmio() )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
}
else
>
> I don't if it has to do with the dom0_max_vcpus xen_cmdline option.
> I lowered it to 2 (the machine has 1 package(s) x 4 core(s) x 2 SMT
> threads) just in case.
No, I don't think it's related to the dom0_max_vcpus option.
>> .
>>
>> Yes, this is possible from the serial console. Press Ctrl-A tree times
>> (to switch to the Xen console), and then 'R' (note the caps).
>>
> PS: Thanks. I'm unable to bring in the xen console, perhaps because
> I'm using the serial console, I don't know. I'll try the physical
> console, just in case.
The Xen console is only available over the serial, pressing Ctrl-A tree
times should bring it up (the keystroke sequence is the same that's
used to change windows on screen).
Roger.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5523EDBE.70709>