On 01/08/2018 10:14, Jan Beulich wrote: >>>> 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.
It is either #VE, or EPT_VIOLATION (as that is literally the definition of how #VE gets raised). With the latter, you get several VMCS fields filled in for you. For the former, you've got to find the guest physical address which the processor dumped the same information into. I think I'll safely stick with my "entire" here. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
