From: Juergen Gross <jgross@suse.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: grub-devel@gnu.org, phcoder@gmail.com, mchang@suse.com,
xen-devel@lists.xen.org
Subject: Re: [PATCH v4 09/11] xen: add capability to load initrd outside of initial mapping
Date: Mon, 22 Feb 2016 14:26:21 +0100 [thread overview]
Message-ID: <56CB0C7D.1050909@suse.com> (raw)
In-Reply-To: <20160222122411.GR3482@olila.local.net-space.pl>
On 22/02/16 13:24, Daniel Kiper wrote:
> On Mon, Feb 22, 2016 at 10:18:38AM +0100, Juergen Gross wrote:
>> On 22/02/16 09:42, Daniel Kiper wrote:
>>> On Mon, Feb 22, 2016 at 07:03:17AM +0100, Juergen Gross wrote:
>>>> Modern pvops linux kernels support an initrd not covered by the initial
>>>> mapping. This capability is flagged by an elf-note.
>>>>
>>>> In case the elf-note is set by the kernel don't place the initrd into
>>>> the initial mapping. This will allow to load larger initrds and/or
>>>> support domains with larger memory, as the initial mapping is limited
>>>> to 2GB and it is containing the p2m list.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
>>>> ---
>>>> V4: rename grub_xen_alloc_end() to grub_xen_alloc_final()
>>>> ---
>>>> grub-core/loader/i386/xen.c | 61 ++++++++++++++++++++++++++++++--------
>>>> grub-core/loader/i386/xen_fileXX.c | 3 ++
>>>> include/grub/xen_file.h | 1 +
>>>> 3 files changed, 52 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
>>>> index 2e12763..22a94ae 100644
>>>> --- a/grub-core/loader/i386/xen.c
>>>> +++ b/grub-core/loader/i386/xen.c
>>>> @@ -58,6 +58,7 @@ struct xen_loader_state {
>>>> grub_uint64_t modules_target_start;
>>>> grub_size_t n_modules;
>>>> int loaded;
>>>> + int alloc_end_called;
>>>
>>> alloc_end_called -> alloc_final_called
>>>
>>>> };
>>>>
>>>> static struct xen_loader_state xen_state;
>>>> @@ -320,6 +321,28 @@ grub_xen_pt_alloc (void)
>>>> }
>>>>
>>>> static grub_err_t
>>>> +grub_xen_alloc_final (void)
>>>> +{
>>>> + grub_err_t err;
>>>> +
>>>> + if (xen_state.alloc_end_called)
>>>> + return GRUB_ERR_NONE;
>>>> + xen_state.alloc_end_called = 1;
>>>
>>> This is not nice. What happens if grub_xen_p2m_alloc() allocate what
>>> is needed and grub_xen_special_alloc() fails?
>>
>> Then grub_xen_alloc_final will fail resulting in boot failure of the
>> new kernel. The memory allocated by the single functions will be freed
>> in case a new boot is attempted (patch 1 and 2).
>>
>>> Maybe grub_xen_p2m_alloc(), grub_xen_special_alloc() and grub_xen_pt_alloc()
>>> should check itself that required regions are allocated properly
>>> (if (something != NULL)) and do nothing if yes.
>>
>> Hmm, with grub_xen_reset() doing appropriate cleanups this would be an
>> option. I think I'll change it as you are suggesting.
>
> It looks that we can completely avoid that stuff. I think that
> grub_xen_alloc_final() should be called conditionally in both
> places/cases. That is all.
Hmm. I think this is less clear, especially taking patch 11 into
account. And I wouldn't like to tie e.g. page table allocation to
something like "if (!xen_state.virt_start_info)" which would result
from that change, now that I've removed xen_state.alloc_end_called as
you suggested.
Juergen
next prev parent reply other threads:[~2016-02-22 13:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 6:03 [PATCH v4 00/11] grub-xen: support booting huge pv-domains Juergen Gross
2016-02-22 6:03 ` [PATCH v4 01/11] xen: make xen loader callable multiple times Juergen Gross
2016-02-22 8:09 ` Daniel Kiper
2016-02-22 6:03 ` [PATCH v4 02/11] xen: avoid memleaks on error Juergen Gross
2016-02-22 8:24 ` Daniel Kiper
2016-02-22 9:06 ` Juergen Gross
2016-02-25 17:38 ` Andrei Borzenkov
2016-02-22 6:03 ` [PATCH v4 03/11] xen: reduce number of global variables in xen loader Juergen Gross
2016-02-22 6:03 ` [PATCH v4 04/11] xen: add elfnote.h to avoid using numbers instead of constants Juergen Gross
2016-02-22 6:03 ` [PATCH v4 05/11] xen: synchronize xen header Juergen Gross
2016-02-22 6:03 ` [PATCH v4 06/11] xen: factor out p2m list allocation into separate function Juergen Gross
2016-02-22 6:03 ` [PATCH v4 07/11] xen: factor out allocation of special pages " Juergen Gross
2016-02-22 6:03 ` [PATCH v4 08/11] xen: factor out allocation of page tables " Juergen Gross
2016-02-22 6:03 ` [PATCH v4 09/11] xen: add capability to load initrd outside of initial mapping Juergen Gross
2016-02-22 8:42 ` Daniel Kiper
2016-02-22 9:18 ` Juergen Gross
2016-02-22 12:24 ` Daniel Kiper
2016-02-22 13:26 ` Juergen Gross [this message]
2016-02-22 6:03 ` [PATCH v4 10/11] xen: modify page table construction Juergen Gross
2016-02-22 9:17 ` Daniel Kiper
2016-02-22 9:29 ` Juergen Gross
2016-02-22 12:18 ` Daniel Kiper
2016-02-22 12:30 ` Juergen Gross
2016-02-22 12:48 ` Daniel Kiper
2016-02-22 13:14 ` Juergen Gross
2016-02-25 18:33 ` Andrei Borzenkov
2016-02-29 9:13 ` Juergen Gross
2016-02-29 12:19 ` Juergen Gross
2016-03-01 3:52 ` Andrei Borzenkov
2016-03-01 5:12 ` [Xen-devel] " Juergen Gross
2016-03-02 9:12 ` Daniel Kiper
2016-03-02 15:43 ` Juergen Gross
2016-03-02 16:04 ` Daniel Kiper
2016-02-22 6:03 ` [PATCH v4 11/11] xen: add capability to load p2m list outside of kernel mapping Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CB0C7D.1050909@suse.com \
--to=jgross@suse.com \
--cc=daniel.kiper@oracle.com \
--cc=grub-devel@gnu.org \
--cc=mchang@suse.com \
--cc=phcoder@gmail.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).