Date: Tue, 07 Apr 2015 17:51:35 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= <gperez@entel.upc.edu> To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <royger@FreeBSD.org> Cc: freebsd-xen@FreeBSD.org Subject: Re: Fwd: Re: Unable to boot with the dom0 xen kernel Message-ID: <5523FD07.1000707@entel.upc.edu> In-Reply-To: <5523EDBE.70709@FreeBSD.org> References: <5523D56B.9040706@entel.upc.edu> <5523D5A7.5040809@entel.upc.edu> <5523EDBE.70709@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/04/2015 16:46, Roger Pau Monné wrote: > > 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 > Removing the assert prevents the panic and thus the machine boots. However I believe the assert was there for a reason, wouldn't it break somewhere else? OTOH, I see the machine has problems handling the interruption from all devices. I see watchdog timeouts from the mpt controller, usb, and network. Even shutting down the machine via ACPI fails (I had to unplug the two PS to shut it down). Probably related with the iommu=no-intremap in the xen_cmdline, isn't it? Btw, the laptop dom0 domain now boots just fine with xen. It was a pekbac (sorry for the noise on that). > 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). Oh, the problem was minicom in the middle. With cu it does work. Thank you. Gustau -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5523FD07.1000707>