[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 2/2] libxl: don't reset device when it is accessible by the guest

On Tue, Dec 18, 2018 at 10:43:38PM +0800, Chao Gao wrote:
> When I destroyed a guest with 'xl destroy', I found the warning
> in msi_set_mask_bit() in Xen was triggered. After adding "WARN_ON(1)"
> to that place, I got the call trace below:
> (XEN) Xen call trace:
> (XEN)    [<ffff82d080281a6a>] msi.c#msi_set_mask_bit+0x1da/0x29b
> (XEN)    [<ffff82d080282e78>] guest_mask_msi_irq+0x1c/0x1e
> (XEN)    [<ffff82d08030ceb9>] vmsi.c#msixtbl_write+0x173/0x1d4
> (XEN)    [<ffff82d08030cf30>] vmsi.c#_msixtbl_write+0x16/0x18
> (XEN)    [<ffff82d0802ffac4>] hvm_process_io_intercept+0x216/0x270
> (XEN)    [<ffff82d0802ffb45>] hvm_io_intercept+0x27/0x4c
> (XEN)    [<ffff82d0802f0e86>] emulate.c#hvmemul_do_io+0x273/0x454
> (XEN)    [<ffff82d0802f10a4>] emulate.c#hvmemul_do_io_buffer+0x3d/0x70
> (XEN)    [<ffff82d0802f2343>] emulate.c#hvmemul_linear_mmio_access+0x35e/0x436
> (XEN)    [<ffff82d0802f2640>] emulate.c#linear_write+0xdd/0x13b
> (XEN)    [<ffff82d0802f3f25>] emulate.c#hvmemul_write+0xbd/0xf1
> (XEN)    [<ffff82d0802d51df>] x86_emulate+0x2249d/0x23c5c
> (XEN)    [<ffff82d0802d861f>] x86_emulate_wrapper+0x2b/0x5f
> (XEN)    [<ffff82d0802f28aa>] emulate.c#_hvm_emulate_one+0x54/0x1b2
> (XEN)    [<ffff82d0802f2a18>] hvm_emulate_one+0x10/0x12
> (XEN)    [<ffff82d080300227>] hvm_emulate_one_insn+0x42/0x14a
> (XEN)    [<ffff82d08030037e>] handle_mmio_with_translation+0x4f/0x51
> (XEN)    [<ffff82d0802f803b>] hvm_hap_nested_page_fault+0x16c/0x6d8
> (XEN)    [<ffff82d08032446a>] vmx_vmexit_handler+0x19b0/0x1f2e
> (XEN)    [<ffff82d08032995a>] vmx_asm_vmexit_handler+0xfa/0x270
> It seems to me that guest is trying to mask a msi while the memory decoding
> of the device is disabled. Performing a device reset without proper method
> to avoid guest's MSI-X operation would lead to this issue.
> The fix is basic - detach pci device before resetting the device.

Seems quite obvious. Do you have any idea why the device was first
reset and then deassigned?

> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.