Re: [Xen-devel] [PATCH] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.08.18 at 10:38, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 01/08/2018 09:23, 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.
>>
>> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel