[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/4] x86/PV: properly set shadow allocation for Dom0

  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 31 Aug 2021 16:25:49 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/4PAPFzahX5ZZq/XpFDgg9zbHBTXaNrXsQGd7kupnw=; b=Or8Pv+0lunS0XX3fvFJ9vXqSXJ6pTYaAfxOEW4uN5/kJxBY90nf1P/iqh/H30mgIF/gpxAqqe4EKLAL8kzz3m2MgNAsC3XqdATFXqONL7CHzDt06Fb62KtThiHIASzfCO8/cE5ZFZchkuM0Hn2EvSvrf5f8ZrGKWIfS2Ca+ubDiMrIAoWwnnBwPI8KUUQPFYE6Uz/rbfN9+2huu/q537SUH5TRNmC0YgVYLlhpF1119l1pLduaPeWZF55ubhMwf28VOfQZORVKfPHmdLwur4hbiTyUTRCLNVNgFIF07uhkE2NE8dK8mMqhNnsVi3SzD/UhYrW7fTSqQT0aF8Wxgzfg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FHSNmLMqdcv/jHFIfteYaW+quY/OuIYRdw+HeirZOboF9y8shV4fRByoFkGXOB8tD1Taxu4Rs4McoGEipIjNq3BXXqFrc3u4bnFxa9H8GViHu5JJE2P6gywGEuUjNxLOXZYqZxCf6JDDeIZw7V8Ng9SVtHKin1nAks/F7YQWGq1cFUDl4wK/n89JJZ9XKecOpUd3PvUcs1lW1uoCZA/gXhZvQH59lCeppHcs4G1qzUsaXLE5a/h96Y0o4ZDT7+24FzJRgGUgNMCbFkZu/JWmxUun+zqpInils6UAVX1/qj402EXWYiOho18Yo1z0n0+P+XKPSnEPElqM7/qZDzcRQw==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 31 Aug 2021 14:25:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 31.08.2021 15:47, Andrew Cooper wrote:
> On 30/08/2021 14:03, Jan Beulich wrote:
>> @@ -933,7 +934,17 @@ int __init dom0_construct_pv(struct doma
>>      if ( opt_dom0_shadow )
>>      {
>> +        bool preempted;
>> +
>>          printk("Switching dom0 to using shadow paging\n");
>> +
>> +        do {
>> +            preempted = false;
>> +            shadow_set_allocation(d, dom0_paging_pages(d, nr_pages),
>> +                                  &preempted);
>> +            process_pending_softirqs();
>> +        } while ( preempted );
> This isn't correct.  The shadow pool is needed even without
> opt_dom0_shadow, because some downstreams have elected not to retain
> upstream's security vulnerability in default setting of opt_pv_l1tf_hwdom.

Are you suggesting to set up a (perhaps large) shadow pool just in
case we need to enable shadow mode on Dom0? And all of this memory
to then remain unused in the majority of cases?

Plus even if so, I'd view this as a 2nd, independent step, largely
orthogonal to the handling of "dom0=shadow". If somebody really
wanted that, I think this should be driven by an explicit setting
of the shadow pool size, indicating the admin is willing to waste
the memory.

I'm further puzzled by "not to retain upstream's security
vulnerability" - are you saying upstream is vulnerable in some way,
while perhaps you (XenServer) are not? In general I don't think I
view downstream decisions as a driving factor for what upstream
does, when the result is deliberately different behavior from

> Also, dom0_paging_pages() isn't a trivial calculation, so should be
> called once and cached.

Sure, can do that. You did notice though that all I did is take
PVH's similar code?




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.