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

Re: [PATCH] x86/shim: fix build when !PV32


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 7 May 2021 12:14:45 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=cTEfHOjGNfS+EPLJAsyAuMcp1j34OhQGU0oOEQMhYgI=; b=LWPry6PUOPf6ayfdOuvKzzWHCShd0xX30I1Nit8pQM6rsKpg/wcWvaSJXff9gPr+CX6bsbafHT1vvS9cUDQU4oQeB38kas+UUSI8+1h9HAsxXKaJWem/I9eqan18e2/LlzbNP24KNq0AdYPsJ/Uti/FSFwQ71zqHDLHeBrlBN8Qw7DTEYhiGwK4HexgA+45+07qc2duT9fOgYVN3Odf4lZLZ/xoC3i473BB9va8/0vY/rOEjF3tIKMBCH06YXyXxFuREqP6CGdb+48oLIRsOxyDgiAss+Q9kycJvstWZDpVKx434ScnvXUakEMZOdAVck6J0Rtdn53jPJorEaFFjtg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N0rBNT0/Zpi/q0gSFvA/MC8EJAIZ9q7MzZ3eJSQhQ74DyEMdYUpMGpaiZxe0uA0Vo5U+XCXXCWkl6ODeTZcj/ITFL10nTtv/k/iSYkhaEro23paHiR8tSONEGRlRICT1LzAfq8wzNXixDPwgW8XjfudTrf0p9e+RLgwPdKrC3hkRzoPxt4jeJVHP67bIv1fSczEpv/Lr3NAW6fWsihbEV2swZfpLuE75DGOueN7seuD2GuAO2s2MjLzYeRlA8C80MSHaW7d9B7st83D5zMe8n/7GgX8XGi0/QB+u3AsI6RSHp7NKgXd/bG28GQ3KgxRqD/z0KDFGJAYdF83tTA+Aag==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Fri, 07 May 2021 10:15:06 +0000
  • Ironport-hdrordr: A9a23:jMdXzqqgNjyP3cvNxPLRm9QaV5sLL9V00zEX/kB9WHVpm5Oj+v xGzc5w6farsl0ssSkb6Ku90KnpewK+yXcH2/hqAV7CZniqhILMFu1fBOTZslrd8kHFl9K1kJ 0QC5SWa+eAQWSS7/yKhjVQeuxIqLbozEnrv5am854Hd3AJV0gU1XYcNu/tKDwSeOApP/oEPa vZwvACiyureHwRYMj+LGICRfL/q9rCk4+jSQIaBjY8gTP+ww+A2frfKVy1zx0eWzRAzfMJ6m 7eiTH04a2lrrWS1gLc7WnO9J5b8eGRi+erRfb8yvT9GA+cyDpAV74RHoFqewpF5N1H3Wxa0+ UkZS1QePibpUmhOF1d6iGdpjUImAxel0MKj2XozkcL6PaJOg7TB6d69P1kWwqc5Ew6sN5m1q VXm2qfqppMFBvF2D/w/t7SSnhR5wGJSFcZ4KcuZkZkIMMjgX5q3PgiFUhuYd099eLBmfYa+c xVfbThDdptACCnhkHizx5SKYaXLwQO9z+9Mzo/U+KuoklroEw=
  • Ironport-sdr: 8Bl84VTAmdh7GC1iPuNLzhpmdaR5IutitRmWgDTVZGNcwMjEyeXEk4KV0UjUgts8GbyLfR2Dv8 kVtKmuAdJD9BBcv9Wr0nBfk5hQenSVtfd9cPfkpW3aMkPHsp+eoLczcCRp+iyCwBwvd8qXzVo2 l8RmWfB4kwEuPhvKrq9ZDP2bl2amIRDay0MUaRFDs4tlNqwOM6JxriFQA2B0EqyMv/JHKtomyJ FWCyQpgUtQzP2w892ngX09MUckHIcsMyXcjDxtdlwuKNNPt0Iuhedt78oW4aoR1moOhW1Lva9G PMs=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, May 07, 2021 at 11:17:26AM +0200, Jan Beulich wrote:
> On 07.05.2021 11:08, Roger Pau Monné wrote:
> > On Fri, May 07, 2021 at 10:34:24AM +0200, Jan Beulich wrote:
> >> On 07.05.2021 10:21, Roger Pau Monné wrote:
> >>> On Fri, May 07, 2021 at 08:22:38AM +0200, Jan Beulich wrote:
> >>>> In this case compat headers don't get generated (and aren't needed).
> >>>> The changes made by 527922008bce ("x86: slim down hypercall handling
> >>>> when !PV32") also weren't quite sufficient for this case.
> >>>>
> >>>> Try to limit #ifdef-ary by introducing two "fallback" #define-s.
> >>>>
> >>>> Fixes: d23d792478db ("x86: avoid building COMPAT code when !HVM && 
> >>>> !PV32")
> >>>> Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >>>>
> >>>> --- a/xen/arch/x86/pv/shim.c
> >>>> +++ b/xen/arch/x86/pv/shim.c
> >>>> @@ -34,8 +34,6 @@
> >>>>  #include <public/arch-x86/cpuid.h>
> >>>>  #include <public/hvm/params.h>
> >>>>  
> >>>> -#include <compat/grant_table.h>
> >>>> -
> >>>>  #undef virt_to_mfn
> >>>>  #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> >>>>  
> >>>> @@ -300,8 +298,10 @@ static void write_start_info(struct doma
> >>>>                                            &si->console.domU.mfn) )
> >>>>          BUG();
> >>>>  
> >>>> +#ifdef CONFIG_PV32
> >>>>      if ( compat )
> >>>>          xlat_start_info(si, XLAT_start_info_console_domU);
> >>>> +#endif
> >>>
> >>> Would it help the compiler logic if the 'compat' local variable was
> >>> made const?
> >>
> >> No, because XLAT_start_info_console_domU is undeclared when there are
> >> no compat headers.
> >>
> >>> I'm wondering if there's a way we can force DCE from the compiler and
> >>> avoid the ifdefs around the usage of compat.
> >>
> >> The issue isn't with DCE - I believe the compiler does okay in that
> >> regard. The issue is with things simply lacking a declaration /
> >> definition. That's no different from e.g. struct fields living
> >> inside an #ifdef - all uses then need to as well, no matter whether
> >> the compiler is capable of otherwise recognizing the code as dead.
> > 
> > Right, I see those are no longer declared anywhere. Since this is
> > gating compat code, would it make more sense to use CONFIG_COMPAT
> > rather than CONFIG_PV32 here?
> 
> I don't think so, no, from the abstract perspective that it's really
> PV that the shim cares about, and hence other causes of COMPAT getting
> selected shouldn't count.

Ack, and we already use CONFIG_PV32 for similar stuff in the file
anyway.

Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

It's just becoming slightly trickier to figure out what do you need to
gate with CONFIG_PV32 IMO.

Thanks, Roger.



 


Rackspace

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