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

[Chao Gao <chao.gao@xxxxxxxxx>]

On Wed, Dec 19, 2018 at 10:00:49AM +0100, Roger Pau Monné wrote:
>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?

TBH, I have no idea.

>
>> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
>
>Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks
Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel