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

Re: [PATCH v1 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Oleksii <oleksii.kurochko@xxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 16 Feb 2023 10:48:54 +0000
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qACx1sSZULQN2eFk3PB9pvE75HPEj9a8g9ahs0ba3sE=; b=bT1T5FvvUmuzSCKm/Vh4ysmlSSOqqtvnyENx81M4cPu6tFRA3y54L5t7ISBRrgzgbgiyt2vRYDNPNTMRbCRz9h3lA7YggTFnSYDDrCu5X8dXY4IwZ+ZFOfs8LHUQ7hcnR+Lq9yTPkoHYVuFfbUIZnVCsO6qaghPLltNVXADULW5tvjyg/WUaIGTl9sp13Gi6rRbwzL/fOUmI84wE3nO+aJSwaCs0iuBN/ZVfkzP/mOK17oQlOeeU8XA738hLZX/eCDS22TUxcYKUT0kzvO9RNZxaMsA3z2kOs21DENQI7Zd59aQQts0uJqSiTCKhXGL2xI04H0d5CYMnp+44IQdIVg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fgMsw6pv6ggkG5VZAUnHRc7JjkB45gN8gtuBL7gHqTG9ko5Ciqs3vAlu2OEVWyk1xVauTym4gvG/RhtOSobltZrm0wX34VL0QSa53xqFzekjcpKtA7CMkAeC7J7iK8ZEF7aAZWy2xvwbqWafF3UK03toiidmlu9fxIL4Lvutk+bsMxhAZc5GJM0STJ7fsBbLo2e8t9pROnJlc+ROCh4yN6vQjJUzO/NUGkTluIk+XA8g+bHYMQ0ARNsBMovqMOYJLkzLvYulWqIFhp2RyuuePRN25NSCveEIOcSiZp1KPjEAWNnMgSHvRtPwmf6tTo6GCGBfACT31mlfKwzjXdL4wA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 16 Feb 2023 10:49:14 +0000
  • Ironport-data: A9a23:pKaLKKgbVdVHP4Fll3ULIFlMX161jhEKZh0ujC45NGQN5FlHY01je htvCDuEPavfZ2D8KY8kaY6z8U0B6pOEmIAwSwRvrys2EiIb9cadCdqndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wbuOgTrWCYmYpHlUMpB4J0XpLg/Q+jpNjne+3CgaMv cKai8DEMRqu1iUc3lg8sspvkzsy+qWt0N8klgZmP6sT5gaAzyB94K83fsldEVOpGuG4IcbiL wrz5OnR1n/U+R4rFuSknt7TGqHdauePVeQmoiM+t5mK2nCulARrukoIHKN0hXNsoyeIh7hMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+ tQbGBpTUzGbt9ukxfXqVtBM3Z8ELOTSadZ3VnFIlVk1DN4AaLWaGuDmwIEd2z09wMdTAfzZe swVLyJ1awjNaAFOPVFRD48imOCvhT/0dDgwRFC9/PJrpTSMilEuluGyaLI5efTTLSlRtm+eq njL4CLSBRYCOcbE4TGE7mitlqnEmiaTtIc6ReLipq8z3Az7Kmo7LE1PRWCakNCClRS+ecJRB BA69hZ2sv1nnKCsZpynN/Gim1aGtBMBX9tbE8Uh9RqAjKHT5m6xAWwJTSVAaZolqdUxTjwp0 XeGmtroAXpkt7j9YXCA8raZqxuiNC5TKnUNDQcfVhcM6dTnpIA1jzrMQ8xlHarzicf6cRnvx xiaoS54gK8c5eYb2qP+8V3ZjjaEopnSUhVz9gjRRnii7A5yeMiifYPA1LTAxfNJLYLcQlzfu nEBwpGa9LpXUsnLkzGRSuIQGr3v/+yCLDDXnV9oGd8m6iip/HmgO4tX5VmSOXtUDyrNQhexC Ge7hO+bzMQ70KeCBUOvX7+MNg==
  • Ironport-hdrordr: A9a23:r2VtRaiOK+esZ0OfEa7EiLVCvHBQXh4ji2hC6mlwRA09TyX5ra 2TdZUgpHrJYVMqMk3I9uruBEDtex3hHP1OkOss1NWZPDUO0VHARO1fBOPZqAEIcBeOldK1u5 0AT0B/YueAd2STj6zBkXSF+wBL+qj6zEiq792usEuEVWtRGsVdB58SMHfiLqVxLjM2YqYRJd 6nyedsgSGvQngTZtTTPAh/YwCSz+e78q4PeHQ9dmca1DU=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16/02/2023 7:31 am, Jan Beulich wrote:
> On 15.02.2023 18:59, Oleksii wrote:
>> Hello Jan and community,
>>
>> I experimented and switched RISC-V to x86 implementation. All that I
>> changed in x86 implementation for RISC-V was _ASM_BUGFRAME_TEXT. Other
>> things are the same as for x86.
>>
>> For RISC-V it is fine to skip '%c' modifier so _ASM_BUGFRAME_TEXT will
>> look like:
>>
>> #define _ASM_BUGFRAME_TEXT(second_frame) \
>>     ".Lbug%=: ebreak\n"   
>>     ".pushsection .bug_frames.%[bf_type], \"a\", @progbits\n"
>>     ".p2align 2\n"
>>     ".Lfrm%=:\n"
>>     ".long (.Lbug%= - .Lfrm%=) + %[bf_line_hi]\n"
>>     ".long (%[bf_ptr] - .Lfrm%=) + %[bf_line_lo]\n"
>>     ".if " #second_frame "\n"
>>     ".long 0, %[bf_msg] - .Lfrm%=\n"
>>     ".endif\n"
>>     ".popsection\n"
> I expect this could be further abstracted such that only the actual
> instruction is arch-specific.
>
>> The only thing I am worried about is:
>>
>> #define _ASM_BUGFRAME_INFO(type, line, ptr, msg) \
>>   [bf_type] "i" (type), ...
>> because as I understand it can be an issue with 'i' modifier in case of
>> PIE. I am not sure that Xen enables PIE somewhere but still...
>> If it is not an issue then we can use x86 implementation as a generic
>> one.
> "i" is not generally an issue with PIE, it only is when the value is the
> address of a symbol. Here "type" is a constant in all cases. (Or else
> how would you express an immediate operand of an instruction in an
> asm()?)

At a guess, the problem isn't type.  It's the line number, which ends up
in a relocation.

That said, I'm not sure an architecture could reasonably function
without a generic 4-byte PC-relative relocation...

~Andrew



 


Rackspace

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