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

Re: [PATCH v1 02/18] introduction of generalized boot info


  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 25 Jul 2022 09:05:00 +0200
  • 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=f1Yw5Bs9b4nFFMGItWddg+suyr26NNRUnjH9jAUQeP8=; b=f3LGZtm+aCaXy3Cn8tmVVyzFlxFG6PCg2di4VSUKDzjAXBtLEJ8n4+RF6utZ1/r55Z/V194QIg/S5ipyFwmYBQyl53rNKBNiRIBNkUB1YBxLBTiuvd2WyZJzfBsKSyymihOGwAvid9GA3ZXGWq1q59HaG4HIqslFde5zWqtQsnEwQQdAXORxCww9RDKfO8I31o946g3AGGB0z1GRuC7ZO2sk0ZbxXqq6TaMwaYax8dNJEb028dDE+u8qCc33x47xrznITp1oS1hh0AxEyE3b0noImDmGc5GctBcaZ1mXHd2Di50TmPmjbgnrnvjeO6h4XpFqiZ2Z8ATGm8R6WzPlOQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JXUjZYiilPFNqOEUTlg815bz7Dk1M2b/wrHWvlvzizr0kr3VTDnxXnkHb5dzfrro6ZdCawUu9Rn+5mcYEuOIAjAorLMZk13hU+01NOJ583ALsBEJWog7XmjQyw1hEGDUReZLvfIn7RGd1vR7rD4nxJIakNRcw164R6YepQcrymNspKMHDxZDLkDy1/lu/96jzj56u+91osHeC+7wZs2WON/sVOXBVMioaJxVYkeA13YQkry6FWTWp3XvNQcnejCT0KQbpF3MRo5rHPGWxmd/EhMuliqrvSuRUauMoks4Hcjnmd3VWgebP7+PLa2PB6GzVyiWaUKDEuDA9rvneHbG/A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: scott.davis@xxxxxxxxxx, christopher.clark@xxxxxxxxxx, 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, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 25 Jul 2022 07:05:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.07.2022 18:01, Daniel P. Smith wrote:
> On 7/21/22 12:00, Jan Beulich wrote:
>> On 21.07.2022 16:28, Daniel P. Smith wrote:
>>> On 7/19/22 09:11, Jan Beulich wrote:
>>>> On 06.07.2022 23:04, Daniel P. Smith wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/arch/x86/include/asm/bootinfo.h
>>>>> @@ -0,0 +1,48 @@
>>>>> +#ifndef __ARCH_X86_BOOTINFO_H__
>>>>> +#define __ARCH_X86_BOOTINFO_H__
>>>>> +
>>>>> +/* unused for x86 */
>>>>> +struct arch_bootstring { };
>>>>> +
>>>>> +struct __packed arch_bootmodule {
>>>>> +#define BOOTMOD_FLAG_X86_RELOCATED      1U << 0
>>>>
>>>> Such macro expansions need parenthesizing.
>>>
>>> Ack.
>>>
>>>>> +    uint32_t flags;
>>>>> +    uint32_t headroom;
>>>>> +};
>>>>
>>>> Since you're not following any external spec, on top of what Julien
>>>> said about the __packed attribute I'd also like to point out that
>>>> in many cases here there's no need to use fixed-width types.
>>>
>>> Oh, I forgot to mention that in the reply to Julien. Yes, the __packed
>>> is needed to correctly cross the 32bit to 64bit bridge from the x86
>>> bootstrap in patch 4.
>>
>> I'm afraid I don't follow you here. I did briefly look at patch 4 (but
>> that really also falls in the "wants to be split" category), but I
>> can't see why a purely internally used struct may need packing. I'd
>> appreciate if you could expand on that.
> 
> Originally, patch 3 and patch 4 were a single patch, and obviously was
> way too large. To split them, I realized I could introduce a temporary
> conversion function that would allow the patch to be split into a post
> start_xen() patch (patch 3) and a pre start_xen() patch, (patch 4). For
> x86, pre start_xen() consists of 3 different entry points. These being
> the classic/traditional/old multiboot1/2 entry, EFI entry, and PVH entry
> (aka Xen Guest). The latter two are all internal, 64bit, but the former
> is located in arch/x86/boot and is compiled as 32bit. I tried different
> approaches to support using a single header between these two
> environments. Ultimately, IMHO, the cleanest approach is what is
> introduced in patch 4 as it enabled the use of Xen types in the
> structures and maintain a single structure that need to be passed
> around. To do this, a 32bit specific version of the structures were
> defined in arch/x86/boot/boot_info32.h that is populated under 32bit
> mode, then they can be fixed up after getting into start_xen() and in
> 64bit code. To ensure no unexpected insertion of padding, I focused on
> ensuring everything was 32bit aligned and packed. As Julien pointed out,
> I messed up with the use of enum as its size is not guaranteed as the
> enum list grows and I forgot to consider keeping pointers 64bit aligned.
> 
> Does that help?

It helps as background info, yes, but I continue to be unhappy with the
new uses of the __packed attribute.

>>>>> +struct __packed arch_boot_info {
>>>>> +    uint32_t flags;
>>>>> +#define BOOTINFO_FLAG_X86_MEMLIMITS      1U << 0
>>>>> +#define BOOTINFO_FLAG_X86_BOOTDEV        1U << 1
>>>>> +#define BOOTINFO_FLAG_X86_CMDLINE        1U << 2
>>>>> +#define BOOTINFO_FLAG_X86_MODULES        1U << 3
>>>>> +#define BOOTINFO_FLAG_X86_AOUT_SYMS      1U << 4
>>>>> +#define BOOTINFO_FLAG_X86_ELF_SYMS       1U << 5
>>>>> +#define BOOTINFO_FLAG_X86_MEMMAP         1U << 6
>>>>> +#define BOOTINFO_FLAG_X86_DRIVES         1U << 7
>>>>> +#define BOOTINFO_FLAG_X86_BIOSCONFIG     1U << 8
>>>>> +#define BOOTINFO_FLAG_X86_LOADERNAME     1U << 9
>>>>> +#define BOOTINFO_FLAG_X86_APM            1U << 10
>>>>> +
>>>>> +    bool xen_guest;
>>>>
>>>> As the example of this, with just the header files being introduced
>>>> here it is not really possible to figure what these fields are to
>>>> be used for and hence whether they're legitimately represented here.
>>>
>>> I can add a comment to clarify these are a mirror of the multiboot
>>> flags. These were mirrored to allow the multiboot flags to be direct
>>> copied and eased the replacement locations where an mb flag is checked.
>>
>> Multiboot flags? The context here is the "xen_guest" field.
> 
> Apologies, I thought you were referring to all the fields and I forgot
> to explain xen_guest. So to clarify, flags is to carry the MB flags
> passed up from the MB entry point and xen_guest is meant to carry the
> xen_guest bool passed up from the PVH/Xen Guest entry point.

That was my guess, but then my request stands: The fields should be
added to the struct at the time they're being made use of.

Jan



 


Rackspace

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