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

Re: [PATCH] x86/shadow: sh_type_to_size[] needs L2H entry when HVM+PV32


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 23 Jan 2023 17:56:02 +0100
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Zk4umC/FbFRIvgxIz3OY95Fco9mLJGiywi6HudqEr78=; b=fg7qDtxyHPHu0N8eOsCSIBKzXzfl9jcxJikfeSMAe9CSp7HEI4PvsfXhDbXIO1+2varLpqq7nLQacOTTB2qZeIX2NendIhBDH6M+9Er9vRm5LrBxir7BNfyg2mLhGN/5k6HQi2Linr8eGBtaGk9P6NEvMH1dQ39P2nmBm9nmMOxTQZoMCkygN5LlfeuLRRQtSlA2nTXXQxnIkDq6WMkcosMN/4VDVMkLpzIRX3mmUt+BOahLsQ8dMYXtUq5WcHKSxvRR7uTsciBTE4bcQDQUSpCdm9jmokWjDqDPw4fIPivHUshA3HCQORCP5c5QIZfJD/EFCFYO7T2X+tBHyb8Akg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U02u1RSaCduk9uRQnkssbLc+JM1FKivTlXOXMMUIYTq+zm+1d2C19WdZpMzkZSJuXVLEIJ1r/pMLD8rJYGYdhxH932GvyzsFzWslIPgCY062yg8hVC/i7k6mHDMcG3m3wh/pXqI1RFoBOmKT4Ex1+BvAnDWyFs+RzpganTrKNKVULzKq4hZgOg4JDqu1VHGfcPN8OJnQYxMD02i+3B6F4Go3RYlqEp6XWSUfn9re/giYb8qP5clT/ZRGXqX2TvECUyjtmwtPXNmr38YeMYXCxEWgMfn8TL0JpRIR1D5o7ay6mUt5D3h1idDyppt1KwFavEWVJzLA1+i64sN+HW2zYQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 23 Jan 2023 16:56:28 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.01.2023 13:49, Jan Beulich wrote:
> On 23.01.2023 13:30, Andrew Cooper wrote:
>> On 23/01/2023 10:47 am, Jan Beulich wrote:
>>> On 23.01.2023 11:43, Andrew Cooper wrote:
>>>> On 23/01/2023 8:12 am, Jan Beulich wrote:
>>>>> While the table is used only when HVM=y, the table entry of course needs
>>>>> to be properly populated when also PV32=y. Fully removing the table
>>>>> entry we therefore wrong.
>>>>>
>>>>> Fixes: 1894049fa283 ("x86/shadow: L2H shadow type is PV32-only")
>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> Erm, why?
>>>>
>>>> The safety justification for the original patch was that this is HVM
>>>> only code.

Coming back to this: There was no such claim. There was a claim about
the type in question being PV32-only, and there was a comparison with
other types which are HVM-only.

>>>>  And it really is HVM only code - it's genuinely compiled out
>>>> for !HVM builds.
>>> Right, and we have logic taking care of the !HVM case. But that same
>>> logic uses this "HVM-only" table when HVM=y also for all PV types.
>>
>> Ok - this is what needs fixing then.
>>
>> This is a layering violation which has successfully tricked you into
>> making a buggy patch.
>>
>> I'm unwilling to bet this will be the final time either...  "this file
>> is HVM-only, therefore no PV paths enter it" is a reasonable
>> expectation, and should be true.
> 
> Nice abstract consideration, but would mind pointing out how you envision
> shadow_size() to look like meeting your constraints _and_ meeting my
> demand of no excess #ifdef-ary? The way I'm reading your reply is that
> you ask to special case L2H _right in_ shadow_size(). Then again see also
> my remark in the original (now known faulty) patch regarding such special
> casing. I could of course follow that route, regardless of HVM (i.e.
> unlike said there not just for the #else part) ...

Actually no, that remark was about the opposite (!PV32) case, so if I
took both together, this would result:

static inline unsigned int
shadow_size(unsigned int shadow_type)
{
#ifdef CONFIG_HVM
#ifdef CONFIG_PV32
    if ( shadow_type == SH_type_l2h_64_shadow )
        return 1;
#endif
    ASSERT(shadow_type < ARRAY_SIZE(sh_type_to_size));
    return sh_type_to_size[shadow_type];
#else
#ifndef CONFIG_PV32
    if ( shadow_type == SH_type_l2h_64_shadow )
        return 0;
#endif
    ASSERT(shadow_type < SH_type_unused);
    return shadow_type != SH_type_none;
#endif
}

I think that's quite a bit worse than using sh_type_to_size[] for all
kinds of guest uniformly when HVM=y. This

static inline unsigned int
shadow_size(unsigned int shadow_type)
{
    if ( shadow_type == SH_type_l2h_64_shadow )
        return IS_ENABLED(CONFIG_PV32);
#ifdef CONFIG_HVM
    ASSERT(shadow_type < ARRAY_SIZE(sh_type_to_size));
    return sh_type_to_size[shadow_type];
#else
    ASSERT(shadow_type < SH_type_unused);
    return shadow_type != SH_type_none;
#endif
}

is also only marginally better, as we really would better avoid any
such open-coding.

Jan



 


Rackspace

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