>>> On 01.08.18 at 10:38, <andrew.coop...@citrix.com> wrote: > On 01/08/2018 09:23, 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. >> >> Anyway - if such a dependency continues to exist, I think it would >> be desirable to mention it in the description. > > Any setup which intercepts #VE defeats the entire purpose of using #VE > in the first place.
Mostly, I agree, but "entire"? You never know how creative people get, and how seeing #VE might better fit their purpose than other "notification" mechanisms. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
