All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC 00/20] Change parts of the shadow interface to be domain based
Date: Mon, 16 Feb 2015 13:35:47 +0000	[thread overview]
Message-ID: <54E1F233.4080102@citrix.com> (raw)
In-Reply-To: <20150216122952.GA49723@deinos.phlegethon.org>

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

  reply	other threads:[~2015-02-16 13:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12 17:15 [PATCH RFC 00/20] Change parts of the shadow interface to be domain based Andrew Cooper
2015-02-12 17:16 ` [PATCH 01/20] x86/shadow: Whitespace cleanup Andrew Cooper
2015-02-12 17:16 ` [PATCH 02/20] x86/shadow: Rename hash_foreach() to hash_vcpu_foreach() Andrew Cooper
2015-02-12 17:16 ` [PATCH 03/20] x86/shadow: Introduce 'd' pointers and clean up use of 'v->domain' Andrew Cooper
2015-02-12 17:16 ` [PATCH 04/20] x86/shadow: Only apply shadow heuristics when in guest context Andrew Cooper
2015-02-19 13:10   ` Tim Deegan
2015-02-19 14:18     ` Andrew Cooper
2015-02-19 15:33     ` [PATCH v2 04/20] x86/shadow: Change the gating of shadow heuristics Andrew Cooper
2015-02-12 17:16 ` [PATCH 05/20] x86/shadow: Alter shadow_hash_{lookup, insert, delete}() to take a domain Andrew Cooper
2015-02-12 17:16 ` [PATCH 06/20] x86/shadow: Alter *_shadow_status() and make_fl1_shadow() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 07/20] x86/shadow: Alter sh_type_{is_pinnable, has_up_pointer}() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 08/20] x86/shadow: Alter OOS functions " Andrew Cooper
2015-02-12 17:16 ` [PATCH 09/20] x86/shadow: Alter shadow_{pro, de}mote() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 10/20] x86/shadow: Alter sh_put_ref() and shadow destroy functions " Andrew Cooper
2015-02-12 17:16 ` [PATCH 11/20] x86/shadow: Alter sh_get_ref() and sh_{, un}pin() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 12/20] x86/shadow: Alter shadow_set_l?e() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 13/20] x86/shadow: Alter sh_{clear_shadow_entry, remove_shadow_via_pointer}() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 14/20] x86/shadow: Alter sh_remove_l?_shadow() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 15/20] x86/shadow: Alter shadow_unhook{_???}_mappings() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 16/20] x86/shadow: Alter sh_rm_write_access_from_???() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 17/20] x86/shadow: Alter sh_remove_{all_}shadows{, _and_parents}() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 18/20] x86/shadow: Alter sh_{remove_all_mappings, rm_mappings_from_l1}() " Andrew Cooper
2015-02-12 17:16 ` [PATCH 19/20] x86/shadow: Alter sh_remove_write_access " Andrew Cooper
2015-02-12 17:16 ` [PATCH 20/20] x86/shadow: Cleanup of vcpu handling Andrew Cooper
2015-02-13 11:42 ` [PATCH RFC 00/20] Change parts of the shadow interface to be domain based Andrew Cooper
2015-02-16 12:29 ` Tim Deegan
2015-02-16 13:35   ` Andrew Cooper [this message]
2015-02-16 18:28     ` Tim Deegan
2015-02-19 12:35       ` Tim Deegan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E1F233.4080102@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.