[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 3/3] x86/PVH: Support relocatable dom0 kernels
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Jason Andryuk <jason.andryuk@xxxxxxx>
- Date: Thu, 14 Mar 2024 15:19:38 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- 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=Qg/6kFamlDBS5RrBwaJRByAveRK72o7QVCM4MUN4aBg=; b=krVPz4D/FWOtjwE4TyTJNLUcwGEFYlSsKwPMzVT4T+Z0mKvMBzitXuEr9zj8PnQQzUOE1qYXYvY9tqqw06sTyUce6zAiOq+yPmOvnHFlxWfeMyEB2J0iRuI8IgLmi5FZwtgn7YU0XjaxTPZ3xgN8mm7+SLkKV5zPajWqxjAOEajKLg4jwIrNGd/l6hQ3Z5qXSUrFeTfOyczJTPDeBOagN60Cblap5Ega5/+U2xuPFiRyvXACyM7ohYUkVIrZdPWTQh13+icG1Ez8/GyyPOl8PsJfVOcXK+cZ7aOXRcZLBgIuiWgAFXVzBUoU50SpRgVeuhAMbwk9NyK2qL18BZEMkQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cl+x09hD3usxbBPSkWEJ9g4gN+CtcfOlhJV8PrzcAIFZaBgbO3tYEpdUK41RObZ7KZZXjs74CECfME5lpliJpeyJ++Zz73XyTBW6fiS76dGfG3L1unVeMqHfz/ZkmRSpVTE295r/spLkrjSDssERT8PKaj9TVE58QzN0TxKcmGokl4/8HI067vWsiVCBG5HQwApi/9iOY+mxraYCUl7KFQsMCYRPINzjGpoXVZV435k6B6a5D/ahAB9Z6ZMfzBPyMAQNO5kC1Z426qKO9r+kmAh5kFGcYI6mgue6puWHO1p+cWQq++JfXufQth6aXoI188LDGOoRSGYsmhi/mdTqig==
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 14 Mar 2024 19:19:53 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2024-03-14 09:31, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,108 @@ static paddr_t __init find_memory(
return INVALID_PADDR;
}
+static bool __init check_load_address(
+ const struct domain *d, const struct elf_binary *elf)
+{
+ paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK;
+ paddr_t kernel_end = PAGE_ALIGN((paddr_t)elf->dest_base + elf->dest_size);
Both casts act on a pointer value. Such cannot legitimately be converted
to paddr_t; it only so happens that paddr_t is effectively the same as
uintptr_t right now. (Same issue again further down.) That said, I notice
we have pre-existing examples of this ...
Yes, I followed existing code. Do you want dest_base to be switched to
a uintptr_t?
+/* Check the kernel load address, and adjust if necessary and possible. */
+static bool __init check_and_adjust_load_address(
+ const struct domain *d, struct elf_binary *elf, struct elf_dom_parms
*parms)
+{
+ paddr_t reloc_base;
+
+ if ( check_load_address(d, elf) )
+ return true;
+
+ if ( parms->phys_align == UNSET_ADDR )
+ {
+ printk("Address conflict and %pd kernel is not relocatable\n", d);
+ return false;
+ }
+
+ reloc_base = find_kernel_memory(d, elf, parms);
+ if ( reloc_base == 0 )
+ {
+ printk("Failed find a load address for the kernel\n");
+ return false;
+ }
+
+ if ( opt_dom0_verbose )
+ printk("Relocating kernel from [%lx, %lx] -> [%lx, %lx]\n",
+ (paddr_t)elf->dest_base,
+ (paddr_t)elf->dest_base + elf->dest_size,
By using %p you clearly can avoid the casts here.
Ok.
+ reloc_base, reloc_base + elf->dest_size);
I'm not convinced %lx is really appropriate for paddr_t.
PRIpaddr exists. It's "016lx" for x86. Using that and %p add lots of 0s:
(XEN) Relocating kernel from [0000000001000000, 000000000202ffff] ->
[0000000002200000, 000000000322ffff]
Regards,
Jason
|
