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. We'll eventually have to cope with this situation because its not one we can architecturally rule out (especially with nested virt in the mix), but intercepting #VE is not something we should make available as a user-available option. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
