[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] XenGT is still regressed on master
Jan, We've noticed that there is still a regression with p2m_ioreq_server P2M type on master. Since the commit 940faf0279 (x86/HVM: split page straddling emulated accesses in more cases) the behavior of write and rmw instruction emulation changed (possibly unintentionally) so that it might not re-enter hvmemul_do_io() on IOREQ completion which should be done in order to avoid breaking IOREQ state machine. What we're seeing instead is a domain crash here: static int hvmemul_do_io( bool_t is_mmio, paddr_t addr, unsigned long *reps, unsigned int ... case STATE_IORESP_READY: vio->io_req.state = STATE_IOREQ_NONE; p = vio->io_req; /* Verify the emulation request has been correctly re-issued */ if ( (p.type != (is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO)) || (p.addr != addr) || (p.size != size) || (p.count > *reps) || (p.dir != dir) || (p.df != df) || (p.data_is_ptr != data_is_addr) || (data_is_addr && (p.data != data)) ) domain_crash(currd); This is happening on processing of the next IOREQ after the one that hasn't been completed properly due to p2mt being changed in IOREQ handler by XenGT kernel module. So it hit HVMTRANS_okay case in linear_write() helper on the way back and didn't re-enter hvmemul_do_io(). The bug could be mitigated by the following patch but since it's you who introduced this helper you might have better ideas how to avoid the problem in a clean way here. --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -1139,13 +1139,11 @@ static int linear_write(unsigned long addr, unsigned int bytes, void *p_data, { unsigned int offset, part1; - case HVMTRANS_okay: - return X86EMUL_OKAY; - case HVMTRANS_bad_linear_to_gfn: x86_emul_pagefault(pfinfo.ec, pfinfo.linear, &hvmemul_ctxt->ctxt); return X86EMUL_EXCEPTION; + case HVMTRANS_okay: case HVMTRANS_bad_gfn_to_mfn: offset = addr & ~PAGE_MASK; if ( offset + bytes <= PAGE_SIZE ) Igor _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |