On 08/01/2018 11:23 AM, Jan Beulich wrote: >>>> On 31.07.18 at 19:19, <ta...@tklengyel.com> wrote: >> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich <jbeul...@suse.com> wrote: >>>>>> On 25.07.18 at 13:49, <a...@bitdefender.com> wrote: >>>> - vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn); >>>> - altp2m_vcpu_update_vmfunc_ve(curr); >>>> + vcpu_altp2m(v).veinfo_gfn = _gfn(a.u.enable_notify.gfn); >>>> + altp2m_vcpu_update_vmfunc_ve(v); >>> >>> I'd like you to outline in the description how you mean an external >>> agent to coordinate the use of this GFN with the guest (and in >>> particular without in-guest agent). >> >> Using #VE without an in-guest agent isn't really possible so this is >> really just about designating the page from dom0 instead of doing it >> with the in-guest agent. Something has to be present in the guest to >> handle the new interrupts coming from #VE after all. > > Not necessarily - the exception could also be intercepted, and the > external agent be informed, with it taking appropriate action.
Right, but the main attraction of a hypervisor-level agent is that it can't be manipulated at all from within the guest, unlike traditional solutions. With that in mind, the in-guest agent should be an optimization-only tool, and not allowed to make its own decisions about the core introspection logic. Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel