|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
>>> On 05.09.18 at 10:14, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 9/5/18 9:56 AM, Jan Beulich wrote:
>>>>> On 04.09.18 at 22:58, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
>>>> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop <apop@xxxxxxxxxxxxxxx> wrote:
>>>>> --- a/xen/arch/x86/hvm/hvm.c
>>>>> +++ b/xen/arch/x86/hvm/hvm.c
>>>>> @@ -4533,8 +4533,7 @@ static int do_altp2m_op(
>>>>> return -EOPNOTSUPP;
>>>>> }
>>>>>
>>>>> - d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
>>>>> - rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
>>>>> + d = rcu_lock_domain_by_any_id(a.domain);
>>>>
>>>> Does rcu_lock_domain_by_any_id work if its from the current domain? If
>>>> not, doesn't that change this function's accessibility to be from
>>>> exclusively usable only by the outside agent?
>>> The code says it should be safe:
>>>
>>> 633 struct domain *rcu_lock_domain_by_any_id(domid_t dom)
>>> 634 {
>>> 635 if ( dom == DOMID_SELF )
>>> 636 return rcu_lock_current_domain();
>>> 637 return rcu_lock_domain_by_id(dom);
>>> 638 }
>>>
>>> as long as dom == DOMID_SELF. I think the old behaviour assumed that
>>> HVMOP_altp2m_vcpu_enable_notify alone would only ever be used from the
>>> current domain, and this change expands its usability (Adrian should
>>> correct me if I'm wrong here).
>>
>> But a guest exposed interface can't be changed like this: If a.domain
>> was ignored for this sub-op before, it needs to continue to be ignored.
>
> Also, technically speaking a.domain is not currently ignored - it's just
> checked against DOMID_SELF:
>
> 4596 case HVMOP_altp2m_vcpu_enable_notify:
> 4597 {
> 4598 struct vcpu *curr = current;
> 4599 p2m_type_t p2mt;
> 4600
> 4601 if ( a.u.enable_notify.pad || a.domain != DOMID_SELF ||
> 4602 a.u.enable_notify.vcpu_id != curr->vcpu_id )
> 4603 {
> 4604 rc = -EINVAL;
> 4605 break;
> 4606 }
Ah, yes, I think that's fine then.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |