Hi, Alex
>> Do we even need a timer? What if we simply spin?
>>
>> for (i = 0; i < 1000; i++) {
>> if (vdev->pci_aer_resume_signaled) {
>> break;
>> }
>> g_usleep(1000);
>> }
>>
>> if (i == 1000) {
>> /* We failed */
>> } else {
>> /* Proceed with reset */
>> }
>>
>> Does QEMU have enough concurrency to do this? Thanks,On 2016/5/25
In my test, it can not work.
vfio_aer_resume_notifier_handler is invoked after vfio_pci_reset.
It is useless to wait in vfio_pci_reset.
Sincerely,
Zhou Jie
14:23, Zhou Jie wrote:
Hi, Alex
3. Stall any access to the device until resume is signaled.
The code below doesn't actually do this, mmaps are disabled, but that
just means any device access will use the slow path through QEMU. That
path is still fully enabled and so is config space access.
I will modify the code and find other way to
stall any access to the device.
I find that to stall any access to the device,
I need modify the following function.
1. vfio_region_read and vfio_region_write
For stalling any access to the device bar region.
2. vfio_vga_read and vfio_vga_write
For stalling any access to the vga device region.
3. vfio_pci_read_config and vfio_pci_write_config
For stalling any access to the device config space.
What will happen if I don't stall any access to the device?
Sincerely,
Zhou Jie
