[PATCH v1 1/5] drm/i915/gvt: GVTg handle enable_pvmmio PVINFO register

[Zhenyu Wang]

On 2018.11.12 01:00:04 +0000, Zhang, Xiaolin wrote:
> On 11/09/2018 10:48 AM, Zhenyu Wang wrote:
> > On 2018.11.05 17:20:45 +0800, Xiaolin Zhang wrote:
> >> implement enable_pvmmio PVINFO register handler in GVTg to
> >> control different level pvmmio optimization within guest.
> >>
> >> report VGT_CAPS_PVMMIO capability in pvinfo page for guest.
> >>
> > Another thing that I think is not consistent for these pv interface
> > which is the guest to host notification is not aligned, some are none
> > e.g share page setup, master irq, some are implicitly through specific
> > MMIO write, e.g execlist port. Which seems not good to me. We should
> > have a formal notification definition for all of them e.g through
> > current 'g2v' notification interface, looks ppgtt update uses that. So
> > host would handle pv request when receiving notification consistently,
> > instead of having different ways which is not good to track.
> >
> > Thanks
> 
> Thanks your point. the host to handle pv request is the same way just
> with different names. Shared page setup is the foundation of PV features
> and only setup once. so shared page setup must be setup first and for
> this trap notification, we have created new shared_page_gpa register for
> this purpose which should be notified  from guest. for master irq
> feature, we crated one more register "check_pending_irq" for guest
> notification to trap from guest to host; for workload submission
> (execlist), we reuse the submit register to trap from guest to host
> instead of creating new one to reduce trap cost (otherwise, we have 2
> traps here , one for submit register and one for notification). for
> ppgtt, since the existing g2v notification can't cover our requirement,
> so we extended 3 more in G2V PPTT notification definition.  Maybe these
> names (shared_page_gpa, check_pedning_irq, submit_reg) are not uniform,
> but they do the same thing for g2v notification.
> 

That's exactly my point that they are not uniformed. Guest driver should
write any update in shared page, then notify gvt host to handle, e.g check_pending_irq,
submit_execlist should all be gvt notification. Then you would have consistent
state, e.g if guest and host has reached agreement on PV action, they would
follow that for sure, any other action would be taken as illegal, e.g write
some MMIO instead, etc.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20181112/57908cd9/attachment.sig>