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

Re: [PATCH 08/65] xen: Annotate fnptr targets from acpi_table_parse()


  • To: Andrew Cooper <amc96@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 13 Dec 2021 08:46:40 +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=e649gei7eQyg68ariLZ7D6yQJEYsBIEInU5nnHRWWWo=; b=PC+lbcB0m3WgyyOIq9G8OhCN/2ZqayDZZzjskhcP+nmivnQ8FEdXmy1HP8a5axV4LY+B424Ds0kU2QCzrlg38pQTNHJa1lDGkyGuf7vO+hkcDUlJAYxqbke3pyLUIDmfYEwXRJnHjpE2ZgoLsSGMDSktKtianVDjUDspoLTjVzdg9DrNmGjG+cgB+/2l3nplO5jU2Aq8IyDaN0gmE0HFpHh8y6B+mQ+2lUoZBVWGmtl3G/4cqMrVuO7O8V+1PGjwXTx0/GHn0VBdQl84laGivysCxH+3oetE6iAqAl6ie/6LVUgM570M8rIwomfc67ND67whG54hvBhih3DK/M/YLQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VT+ucT4SQewdx6SQHlId0gV5x6FDFNuiCuRpcFuLtzXrOBCUC0ynI4ApBvcfXlPhdmbtOzEsJhc197YBa758aZi4rfDESyzBTTb+r8XzT5JVDBc456zBBFfgEPNNXTntd6dFa5MZLF/jft2GOglExGFPv8raUtAE28OOPpknIdOnKoxHwumu2v2YGDcgidwd3VRywOP+QvDzi/0UmvPGe3/jqexFZHWYaNkBXLxHxDORDy/DXoI2I/ldxHKukZ6MGeNzur9ABekcSGPtRStReybX/x7VmN/e4suBr+/6lDnN+SloXAYiEY/pINcd4aHtg7SSK5xEr3HWTaqnPuPBBw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 13 Dec 2021 07:47:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.12.2021 15:44, Andrew Cooper wrote:
> On 06/12/2021 08:36, Jan Beulich wrote:
>> On 26.11.2021 13:33, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> Elsewhere in this file we have
>>
>>         rc = map ?   map_mmio_regions(d, _gfn(pfn), nr_pages, _mfn(pfn))
>>                  : unmap_mmio_regions(d, _gfn(pfn), nr_pages, _mfn(pfn));
>>
>> which has been in this shape only as of commit e3b418ac4919
>> ("x86/pvh-dom0: Remove unnecessary function pointer call from
>> modify_identity_mmio()"). Aren't we relying on the compiler not
>> transforming this back into the earlier
>>
>>         rc = (map ? map_mmio_regions : unmap_mmio_regions)
>>              (d, _gfn(pfn), nr_pages, _mfn(pfn));
>>
>> ?
> 
> That old code was especially dumb even before retpoline.  See also the
> damage caused by c/s 245a320ce2.

I must be lacking context here - what damage did that one cause again?
Or which subsequent fix of that damage am I overlooking when going
through the further commits on top of that one?

> Yes, we are relying on the compiler not to do transformations behind our
> backs, but it won't of its own accord.
> 
>>  And aren't we further relying on the compiler not transforming direct
>> calls into indirect ones for other reasons (I recall Microsoft's compiler
>> being pretty aggressive about this when the same function was called
>> more than once in close succession, it at least certain past versions)?
> 
> That sounds like a broken compiler.
> 
> There are legal cases where a direct call has to turn into an indirect
> one, and that's when we need to traverse more than disp32 distance.

Right, but that's certainly not happing anywhere in (relevant) practice
withing a single compiled binary.

> But without going to a larger mcmodel, we'd get linker errors before
> that becomes a problem, because R_X86_64_PLT32 relocations can't be
> retrofitted into an indirect call at link time.

I guess I don't see a connection to a PLT reloc: There wouldn't be any
if the compiler chose to make an indirect call out of a direct one. It
would be simple PC-relative relocations (generally coming from a RIP-
relative LEA) instead.

Jan

>> Is the widened effect of the annotation intended to also guarantee that
>> indirect calls will not be produced by the compiler for any reason when
>> the annotation is absent on a targeted function's declaration?
> 
> That would be one for the clang and gcc developers.
> 
> I don't see a plausible problem here.
> 
> ~Andrew
> 




 


Rackspace

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