[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.