Re: [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

2021-11-09 Thread Wang, Zhi A
On 11/9/2021 12:58 PM, h...@lst.de wrote: > On Tue, Nov 09, 2021 at 10:51:27AM +, Wang, Zhi A wrote: >> Can you elaborate more about this? We need the hash query from the table >> ASAP when the hypervisor trapped a mmio access. It's a critical path and >> we tried different data structure in th

Re: [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

2021-11-09 Thread Jani Nikula
On Tue, 09 Nov 2021, "Wang, Zhi A" wrote: > On 11/9/2021 9:00 AM, Jani Nikula wrote: >> On Mon, 08 Nov 2021, Zhi Wang wrote: >>> From: Zhi Wang >>> >>> To support the new mdev interfaces and the re-factor patches from >>> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g >

Re: [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

2021-11-08 Thread Jani Nikula
On Mon, 08 Nov 2021, Zhi Wang wrote: > From: Zhi Wang > > To support the new mdev interfaces and the re-factor patches from > Christoph, which moves the GVT-g code into a dedicated module, the GVT-g > MMIO snapshot still needs to be saved in i915 so that the inital clean HW > state can be used fo

[PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

2021-11-08 Thread Zhi Wang
From: Zhi Wang To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g MMIO snapshot still needs to be saved in i915 so that the inital clean HW state can be used for the further vGPU. Seperate the tracked MMIO tab