Re: [Xen-devel] [PATCH v2 2/4] xen: introduce grant_map_exists

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.10.14 at 15:46, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Mon, 6 Oct 2014, Jan Beulich wrote:
>> >>> On 06.10.14 at 15:08, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > The other approach to do this, that I avoided because it is slower (2
>> > spinlocks instead of 1), is to use the existing mapcount function.
>> > mapcount is based on:
>> > 
>> > for ( handle = 0; handle < lgt->maptrack_limit; handle++ )
>> > 
>> > do you think it is better?
>> 
>> No, that's worse: This is the Dom0 side of things, and the loop
>> bound would still be controlled by that same command line option.
>> 
>> So between the two, the original solution would be better, and
>> maybe enforcing a lower limit on DomU-s might actually be an
>> option.
> 
> What about keeping track of the highest ref number actually used so far?
> I could use that as upper limit instead of the theoretical max. It would
> also make the execution faster.

But the loops are already using a value on the order of the high
watermark, not the theoretical one. I.e. you're not alway looping
for a long time, it is just possible for this to happen.

>> Btw., one more thing I think I forgot in the reply to patch 3:
>> Since you intentionally only care about remote pages, shouldn't
>> you check owner != d after page_get_owner_and_reference()?
> 
> The problem is that with complex scenarios, such as guest disks over
> iscsi, or disk frontend and backend both in dom0, I am afraid that the
> "foreign" page could actually end up belonging to the caller domain.
> Also it is not really a security issue calling an hypercall to do cache
> flush on your own pages, just inefficient. These are the reasons why I
> removed that check.

Makes sense.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel