Re: [Xen-devel] [PATCH RFC 00/20] Change parts of the shadow interface to be domain based

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/02/15 12:29, Tim Deegan wrote:
> Hi,
>
> Thanks for this; I think the code looks a lot saner with all the
> vcpu<->domain fiddling removed. :)
>
> At 17:15 +0000 on 12 Feb (1423757759), Andrew Cooper wrote:
>> The purpose of this series is to prevent toolstack entry points into the
>> shadow code from passing d->vcpu[0] for actions which are inherenly domain
>> wide.  It also fixes the fact that shadow heuristics were being applied to
>> vcpu 0 for toolstack-initiated actions.
>>
>> This series is composed mostly of mechanical changes.  The only patches which
>> have a practical difference on shadow execution are patches 4 and 20
> So having read the series, you can add my Reviewed-by: to all except 4
> and 20.  20 looks probably OK but I want to give it a second pass.

20 is no practical change.  All the patched functions were ones which
had a d in their hand and had to juggle for a v to use the shadow API. 
The affected APIs now take d's instead of v's which means the v juggling
can be removed.


> 4 definitely needs some thought -- in particular v == current is not the
> same as d == current->domain.  I wonder if there's some better test;
> maybe also checking that current is in the right mode will help.

The result is still the same in that you can derive a valid v when
running in the context of the target d.

The change specifically causes codepaths running in the context of the
toolstack domain to not perform shadow shootdown heuristics.

(It was you who suggested this, although I believe that we were down the
pub at the time ;) )

> Let me think about it and I'll review again later in the week.  I'll want
> to have a look at the remaining users of the vcpu variant hash_foreach
> as well.

There are certainly more codepaths which could be turned to taking a
domain.  I limited this series just to adjusting the toolstack
entrypoints into the shadow code.

There are several codepaths are almost completely domain generic, other
than needing to check whether a vcpu has EFER.NX set or not, which
causes any codepath which creates shadows to still be vcpu specific.

~Andrew


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