Sorry, but I have to resend this in a separate thread for better visibility.
Back ground:
After backporting this patch to fix my PVHVM interrupt missing issue in
4.1.3:
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01909.html
I find side effect for pure HVM guest.
http://lists.xen.org/archives/html/xen-devel/2012-12/msg00208.html
I had a follow up thread to analysis the issue and post it again here:
Hi, it seems that the patch has some side effect on pure HVM guest.
>> For openelec 2.0 guest, which is based on linux 3.2.x with PVOP disabled,
>> I see such syndrome in qemu-dm-xxx.log:
>>
>> pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit
>> support??
>> pt_pci_write_config: Internal error: Invalid write emulation return
>> value[-1]. I/O emulator exit.
>>
>> The guest dies immediately after the log, I have no way to check guest
>> kernel log.
>> Without the patch, this guest can boot without obvious error log even the
>> VGA passthrough does not quite work.
>> I'll check the code to see what does these log mean...
>>
>
> I did some analysis and it really looks like a bug to me.
> Since this is a patch back-ported from 4.2.0, I would like to ask is there
> any follow up patch that would fix this issue?
> Please see my analysis below:
>
> Here is part of the qemu-dm log, with debug log enabled at compile time:
>
> dm-command: hot insert pass-through pci dev
> register_real_device: Assigning real physical device 00:1b.0 ...
> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No
> such file or directory: 0x0:0x1b.0x0
> pt_register_regions: IO region registered (size=0x00004000
> base_addr=0xf7c10004)
> pt_msi_setup: msi mapped with pirq 36
> pci_intx: intx=1
> register_real_device: Real physical device 00:1b.0 registered successfuly!
> IRQ type = MSI-INTx
> ...
> pt_pci_read_config: [00:06.0]: address=0000 val=0x0000*8086* len=2
> pt_pci_read_config: [00:06.0]: address=0002 val=0x0000*1e20* len=2
> ...
> *pt_pci_write_config: [00:06.0]: address=0068* val=0x00000000 len=4
> ...
> pt_pci_write_config: [00:06.0]: address=0062 val=0x00000081 len=2
> *pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation*
> pci_intx: intx=1
> *pt_msi_disable: Unmap msi with pirq 36*
> pt_msgctrl_reg_write: setup msi for dev 30
> pt_msi_setup: msi mapped with pirq 36
> pt_msi_update: Update msi with pirq 36 gvec 51 gflags 1303
> pt_pci_read_config: [00:06.0]: address=0062 val=0x00000081 len=2
> pt_pci_write_config: [00:06.0]: address=0062 val=0x00000081 len=2
> pt_pci_write_config: [00:06.0]: address=0064 val=0xfee0300c len=4
> *pt_pci_write_config: [00:06.0]: address=0068* val=0x00000000 len=4
>
> pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit
> support??
> pt_pci_write_config: Internal error: Invalid write emulation return
> value[-1]. I/O emulator exit.
>
>
> Here the device in question should is the audio controller, 00:1b.0 in the
> host, which is 64 bit capable:
> 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
> Family High Definition Audio Controller (rev 04)
> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee00378 Data: 0000
>
> And there is also a successful write to offset 0x68 above, while the
> second write fails the I/O emulator.
>
>
> The patch added pt_msi_disable() call into *pt_msgctrl_reg_write() *function,
> And the pt_msi_disable() function has these lines:
> out:
> /* clear msi info */
> dev->msi->flags = 0;
> dev->msi->pirq = -1;
> dev->msi_trans_en = 0;
>
> As a result, the flags are cleared -- this is new to the patch.
> And I believe this change caused the failure in pt_msgaddr64_write():
>
> 3882 /* check whether the type is 64 bit or not */
> 3883 if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT))
> 3884 {
> 3885 /* exit I/O emulator */
> 3886 PT_LOG("Error: why comes to Upper Address without 64 bit
> support??\n");
> 3887 return -1;
> 3888 }
>
>
> I only see flags setup in pt_msgctrl_reg_init() function. I guess this is
> not called this time.
>
> Thanks,
> Timothy
>
Back ground:
After backporting this patch to fix my PVHVM interrupt missing issue in
4.1.3:
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01909.html
I find side effect for pure HVM guest.
http://lists.xen.org/archives/html/xen-devel/2012-12/msg00208.html
I had a follow up thread to analysis the issue and post it again here:
Hi, it seems that the patch has some side effect on pure HVM guest.
>> For openelec 2.0 guest, which is based on linux 3.2.x with PVOP disabled,
>> I see such syndrome in qemu-dm-xxx.log:
>>
>> pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit
>> support??
>> pt_pci_write_config: Internal error: Invalid write emulation return
>> value[-1]. I/O emulator exit.
>>
>> The guest dies immediately after the log, I have no way to check guest
>> kernel log.
>> Without the patch, this guest can boot without obvious error log even the
>> VGA passthrough does not quite work.
>> I'll check the code to see what does these log mean...
>>
>
> I did some analysis and it really looks like a bug to me.
> Since this is a patch back-ported from 4.2.0, I would like to ask is there
> any follow up patch that would fix this issue?
> Please see my analysis below:
>
> Here is part of the qemu-dm log, with debug log enabled at compile time:
>
> dm-command: hot insert pass-through pci dev
> register_real_device: Assigning real physical device 00:1b.0 ...
> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No
> such file or directory: 0x0:0x1b.0x0
> pt_register_regions: IO region registered (size=0x00004000
> base_addr=0xf7c10004)
> pt_msi_setup: msi mapped with pirq 36
> pci_intx: intx=1
> register_real_device: Real physical device 00:1b.0 registered successfuly!
> IRQ type = MSI-INTx
> ...
> pt_pci_read_config: [00:06.0]: address=0000 val=0x0000*8086* len=2
> pt_pci_read_config: [00:06.0]: address=0002 val=0x0000*1e20* len=2
> ...
> *pt_pci_write_config: [00:06.0]: address=0068* val=0x00000000 len=4
> ...
> pt_pci_write_config: [00:06.0]: address=0062 val=0x00000081 len=2
> *pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation*
> pci_intx: intx=1
> *pt_msi_disable: Unmap msi with pirq 36*
> pt_msgctrl_reg_write: setup msi for dev 30
> pt_msi_setup: msi mapped with pirq 36
> pt_msi_update: Update msi with pirq 36 gvec 51 gflags 1303
> pt_pci_read_config: [00:06.0]: address=0062 val=0x00000081 len=2
> pt_pci_write_config: [00:06.0]: address=0062 val=0x00000081 len=2
> pt_pci_write_config: [00:06.0]: address=0064 val=0xfee0300c len=4
> *pt_pci_write_config: [00:06.0]: address=0068* val=0x00000000 len=4
>
> pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit
> support??
> pt_pci_write_config: Internal error: Invalid write emulation return
> value[-1]. I/O emulator exit.
>
>
> Here the device in question should is the audio controller, 00:1b.0 in the
> host, which is 64 bit capable:
> 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
> Family High Definition Audio Controller (rev 04)
> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee00378 Data: 0000
>
> And there is also a successful write to offset 0x68 above, while the
> second write fails the I/O emulator.
>
>
> The patch added pt_msi_disable() call into *pt_msgctrl_reg_write() *function,
> And the pt_msi_disable() function has these lines:
> out:
> /* clear msi info */
> dev->msi->flags = 0;
> dev->msi->pirq = -1;
> dev->msi_trans_en = 0;
>
> As a result, the flags are cleared -- this is new to the patch.
> And I believe this change caused the failure in pt_msgaddr64_write():
>
> 3882 /* check whether the type is 64 bit or not */
> 3883 if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT))
> 3884 {
> 3885 /* exit I/O emulator */
> 3886 PT_LOG("Error: why comes to Upper Address without 64 bit
> support??\n");
> 3887 return -1;
> 3888 }
>
>
> I only see flags setup in pt_msgctrl_reg_init() function. I guess this is
> not called this time.
>
> Thanks,
> Timothy
>