Re: [Xen-devel] [PATCH v1] x86/altp2m: Add hypercall to create a new view and set sve bits

[Jan Beulich <jbeulich@suse.com>]

On 04.09.2019 13:51, Alexandru Stefan ISAILA wrote:
> 
> 
> On 03.09.2019 18:52, Jan Beulich wrote:
>> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
>>> @@ -1355,6 +1355,23 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>>>       ept = &p2m->ept;
>>>       ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
>>>       d->arch.altp2m_eptp[i] = ept->eptp;
>>> +
>>> +    if ( set_sve )
>>> +    {
>>> +        unsigned long gfn = 0, max_gpfn = domain_get_maximum_gpfn(d);
>>> +
>>> +        for( ; gfn < max_gpfn; ++gfn )
>>> +        {
>>> +            mfn_t mfn;
>>> +            p2m_access_t a;
>>> +            p2m_type_t t;
>>> +
>>> +            altp2m_get_effective_entry(p2m, _gfn(gfn), &mfn, &t, &a,
>>> +                                       AP2MGET_query);
>>> +            p2m->set_entry(p2m, _gfn(gfn), mfn, PAGE_ORDER_4K, t, a, true);
>>> +
>>> +        }
>>> +    }
>>>   }
>>
>> How long is this loop going to take for a huge guest? IOW how
>> come there's no preemption in here, or some other mechanism
>> to bound execution time?
> 
> Because this is done for the initialization of a new view and the p2m is 
> locked.

Well, this makes handling this the way you want it close to
impossible, but is not an argument against the need for preemption
here. Just like it had turned out to be unreasonable to
preemptively handle other P2M adjustments (which is why
p2m-ept.c:resolve_misconfig() and p2m-pt.c:do_recalc() got
introduced), I'm afraid you'll have to use some other technique
here (possibly building on top of the mentioned functions).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel