|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/4] xen: introduce grant_map_exists
>>> On 02.10.14 at 13:34, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Thu, 2 Oct 2014, Jan Beulich wrote:
>> >>> On 02.10.14 at 12:02, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > --- a/xen/common/grant_table.c
>> > +++ b/xen/common/grant_table.c
>> > @@ -484,6 +484,38 @@ static int _set_status(unsigned gt_version,
>> > return _set_status_v2(domid, readonly, mapflag, shah, act,
> status);
>> > }
>> >
>> > +bool_t grant_map_exists(struct domain *ld,
>> > + struct grant_table *rgt,
>> > + unsigned long mfn)
>> > +{
>> > + struct active_grant_entry *act;
>> > + grant_ref_t ref;
>> > + bool_t ret = 0;
>> > +
>> > + spin_lock(&rgt->lock);
>> > +
>> > + for ( ref = 0; ref != nr_grant_entries(rgt); ref++ )
>> > + {
>> > + act = &active_entry(rgt, ref);
>> > +
>> > + if ( !act->pin )
>> > + continue;
>> > +
>> > + if ( act->domid != ld->domain_id )
>> > + continue;
>> > +
>> > + if ( act->frame != mfn )
>> > + continue;
>> > +
>> > + ret = 1;
>> > + break;
>> > + }
>> > +
>> > + spin_unlock(&rgt->lock);
>> > +
>> > + return ret;
>>
>> By the time you get here the information you return is stale. Is that
>> not a problem for the caller? And if it's not, why would it check in the
>> first place?
>
> This is just a security check to make sure that the caller is allowed to
> cache flush the memory range. Even if it is a bit stale I think is OK:
> it is not possible for the memory to have already been reused somewhere
> else.
Why not? Especially when Xen itself runs virtualized, the time
window is arbitrarily large.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |