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

Re: [PATCH v7 2/2] x86/PVH: Support relocatable dom0 kernels


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Jason Andryuk <jason.andryuk@xxxxxxx>
  • Date: Thu, 18 Apr 2024 10:34:05 -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=yoy4dU8NV/J57PhKr72rCjHiZMtO/GRiyuNsZvG+CcA=; b=WZkRNTSAxVDER5gYMo04Ui9YVe8MnWIDIH/BKLwSveqsNm7WI2+eJNy0vD+ipAjxRpDMuKZ8AtKyO8m+ywtAVCwM3C2zTrX7j+6haoWr48PYSog4tT2u6tIPD7anO29OodcVNUw7rrcaNJqIqmIHx3Qv1kbM3GMQA5F/UvOcI2nFYIzhkhLTH4t86g8QqCtboNpSmchz2p7z/9+FEHhOeY2UtayNbuUZEalvS/oAaj0Re/lcBwmdHeDZGeQShs4gximyx5M7ZcK5QHRegBf5LT6uFS09O5/vyHl+vx+tlyk4TibXKm03QnNXGU0ILBLUhYLWfmfRBq4v0ZYT/ZMpIA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VZ3e22NxPcIooj0B1t52w6fXE/J64DT4Cl4HZ/tIdzdnSXzKpeQ7q1zbaIHJ84utxwcMSkcAZCvgmU4Db6fulGZ63GtFzEhrGDar2ScI0hT78/00GkjYh+UNzCyGVlxAeDpErg2RsH4mS5iKdwH4H8ZqCqyNuZfPKNVdpohgG1G9s1+7pCROQ/+l9P4AkKro6Ko3Cd6G6PJScCGc46JPzBGlvyPtd8WaYVZ2fBMJXTvmC9yEi3Ern4Eo51rLGp5Yqv86LZhFYxDu+eKVG2a+/73teiGMnkIJVNkBG6Ob0hjKqa4SlzsBIscr/Nl5C/PzHaEDek4pKusv5+xYACoEkA==
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 18 Apr 2024 14:34:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 2024-04-17 09:24, Jan Beulich wrote:
On 08.04.2024 18:56, Jason Andryuk wrote:
On 2024-04-08 03:00, Jan Beulich wrote:
On 04.04.2024 23:25, Jason Andryuk wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,111 @@ 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 = (uintptr_t)elf->dest_base;
+    paddr_t kernel_end = kernel_start + elf->dest_size;
+    unsigned int i;

While properly typed here, ...

+static paddr_t __init find_kernel_memory(
+    const struct domain *d, struct elf_binary *elf,
+    const struct elf_dom_parms *parms)
+{
+    paddr_t kernel_size = elf->dest_size;
+    unsigned int align;
+    int i;

... I must have missed when this was changed to plain int. It should have
been unsigned int here, too, ...

+    if ( parms->phys_align != UNSET_ADDR32 )
+        align = parms->phys_align;
+    else if ( elf->palign >= PAGE_SIZE )
+        align = elf->palign;
+    else
+        align = MB(2);
+
+    /* Search backwards to find the highest address. */
+    for ( i = d->arch.nr_e820 - 1; i >= 0 ; i-- )

... with this suitably adjusted. However, I'm not going to change this while
committing, to avoid screwing up.

I intentionally changed this.  Looping downwards, a signed int allows
writing the check naturally with i >= 0.  I think it's clearer when
written this way.

Just to clarify: Is

     for ( i = d->arch.nr_e820; i--; )

any less clear?

It's not something I normally write, so I had to think about it more. If you are already familiar with such a construct, then that isn't an issue for you.

Your way is more subtle in my opinion because it relies on the post decrement to ensure correct bounds within the loop body. I prefer i >= 0 because it clearly states the valid index values.

Is your main concern that you only want unsigned values as array indices?

(While replying I also notice there's a stray blank
in the for() you have, ahead of the 2nd semicolon.)

Sorry about that.

Regards,
Jason



 


Rackspace

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