[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
On 08/01/2018 11:23 AM, Jan Beulich wrote: >>>> On 31.07.18 at 19:19, <tamas@xxxxxxxxxxxxx> wrote: >> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>>> On 25.07.18 at 13:49, <apop@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |