All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>,
	Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, kvm-ppc@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH 0/7] kvmtool: Cleanup kernel loading
Date: Mon, 02 Nov 2015 16:03:03 +0000	[thread overview]
Message-ID: <56378937.8050504@arm.com> (raw)
In-Reply-To: <CAK7xexmj2wKknkeMQA7Jj5d_cmfe4PtY4B3vGavesT_V8VoBMA@mail.gmail.com>

Hi Dimitri,

On 02/11/15 15:17, Dimitri John Ledkov wrote:
> On 2 November 2015 at 14:58, Will Deacon <will.deacon@arm.com> wrote:
>> On Fri, Oct 30, 2015 at 06:26:53PM +0000, Andre Przywara wrote:
>>> Hi,
>>
>> Hello Andre,
>>
>>> this series cleans up kvmtool's kernel loading functionality a bit.
>>> It has been broken out of a previous series I sent [1] and contains
>>> just the cleanup and bug fix parts, which should be less controversial
>>> and thus easier to merge ;-)
>>> I will resend the pipe loading part later on as a separate series.
>>>
>>> The first patch properly abstracts kernel loading to move
>>> responsibility into each architecture's code. It removes quite some
>>> ugly code from the generic kvm.c file.
>>> The later patches address the naive usage of read(2) to, well, read
>>> data from files. Doing this without coping with the subtleties of
>>> the UNIX read semantics (returning with less or none data read is not
>>> an error) can provoke hard to debug failures.
>>> So these patches make use of the existing and one new wrapper function
>>> to make sure we read everything we actually wanted to.
>>> The last patch moves the ARM kernel loading code into the proper
>>> location to be in line with the other architectures.
>>>
>>> Please have a look and give some comments!
>>
>> Looks good to me, but I'd like to see some comments from some mips/ppc/x86
>> people on the changes you're making over there.
> 
> Looks mostly good to me, as one of the kvmtool down streams. Over at
> https://github.com/clearlinux/kvmtool we have some patches to tweak
> the x86 boot flow, which will need rebasing/retweaking) specifically
> this commit here -
> https://github.com/clearlinux/kvmtool/commit/a8dee709f85735d16739d0eda0cc00d3c1b17477

Awesome - I was actually thinking about coding something like this!
In the last week I move the MIPS ELF loading out of mips/ into /elf.c to
be able to load kvm-unit-tests' tests (which are Multiboot/ELF). As
multiboot requires entering in protected mode, I was thinking about
changing kvmtool to support entering a guest directly in protected mode
- seems like this is mostly what you've done here already.

Looks like we should both post our patches to merge them somehow ;-)

Cheers,
Andre.

WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara@arm.com>
To: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>,
	Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, kvm-ppc@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH 0/7] kvmtool: Cleanup kernel loading
Date: Mon, 2 Nov 2015 16:03:03 +0000	[thread overview]
Message-ID: <56378937.8050504@arm.com> (raw)
In-Reply-To: <CAK7xexmj2wKknkeMQA7Jj5d_cmfe4PtY4B3vGavesT_V8VoBMA@mail.gmail.com>

Hi Dimitri,

On 02/11/15 15:17, Dimitri John Ledkov wrote:
> On 2 November 2015 at 14:58, Will Deacon <will.deacon@arm.com> wrote:
>> On Fri, Oct 30, 2015 at 06:26:53PM +0000, Andre Przywara wrote:
>>> Hi,
>>
>> Hello Andre,
>>
>>> this series cleans up kvmtool's kernel loading functionality a bit.
>>> It has been broken out of a previous series I sent [1] and contains
>>> just the cleanup and bug fix parts, which should be less controversial
>>> and thus easier to merge ;-)
>>> I will resend the pipe loading part later on as a separate series.
>>>
>>> The first patch properly abstracts kernel loading to move
>>> responsibility into each architecture's code. It removes quite some
>>> ugly code from the generic kvm.c file.
>>> The later patches address the naive usage of read(2) to, well, read
>>> data from files. Doing this without coping with the subtleties of
>>> the UNIX read semantics (returning with less or none data read is not
>>> an error) can provoke hard to debug failures.
>>> So these patches make use of the existing and one new wrapper function
>>> to make sure we read everything we actually wanted to.
>>> The last patch moves the ARM kernel loading code into the proper
>>> location to be in line with the other architectures.
>>>
>>> Please have a look and give some comments!
>>
>> Looks good to me, but I'd like to see some comments from some mips/ppc/x86
>> people on the changes you're making over there.
> 
> Looks mostly good to me, as one of the kvmtool down streams. Over at
> https://github.com/clearlinux/kvmtool we have some patches to tweak
> the x86 boot flow, which will need rebasing/retweaking) specifically
> this commit here -
> https://github.com/clearlinux/kvmtool/commit/a8dee709f85735d16739d0eda0cc00d3c1b17477

Awesome - I was actually thinking about coding something like this!
In the last week I move the MIPS ELF loading out of mips/ into /elf.c to
be able to load kvm-unit-tests' tests (which are Multiboot/ELF). As
multiboot requires entering in protected mode, I was thinking about
changing kvmtool to support entering a guest directly in protected mode
- seems like this is mostly what you've done here already.

Looks like we should both post our patches to merge them somehow ;-)

Cheers,
Andre.

WARNING: multiple messages have this Message-ID (diff)
From: andre.przywara@arm.com (Andre Przywara)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/7] kvmtool: Cleanup kernel loading
Date: Mon, 2 Nov 2015 16:03:03 +0000	[thread overview]
Message-ID: <56378937.8050504@arm.com> (raw)
In-Reply-To: <CAK7xexmj2wKknkeMQA7Jj5d_cmfe4PtY4B3vGavesT_V8VoBMA@mail.gmail.com>

Hi Dimitri,

On 02/11/15 15:17, Dimitri John Ledkov wrote:
> On 2 November 2015 at 14:58, Will Deacon <will.deacon@arm.com> wrote:
>> On Fri, Oct 30, 2015 at 06:26:53PM +0000, Andre Przywara wrote:
>>> Hi,
>>
>> Hello Andre,
>>
>>> this series cleans up kvmtool's kernel loading functionality a bit.
>>> It has been broken out of a previous series I sent [1] and contains
>>> just the cleanup and bug fix parts, which should be less controversial
>>> and thus easier to merge ;-)
>>> I will resend the pipe loading part later on as a separate series.
>>>
>>> The first patch properly abstracts kernel loading to move
>>> responsibility into each architecture's code. It removes quite some
>>> ugly code from the generic kvm.c file.
>>> The later patches address the naive usage of read(2) to, well, read
>>> data from files. Doing this without coping with the subtleties of
>>> the UNIX read semantics (returning with less or none data read is not
>>> an error) can provoke hard to debug failures.
>>> So these patches make use of the existing and one new wrapper function
>>> to make sure we read everything we actually wanted to.
>>> The last patch moves the ARM kernel loading code into the proper
>>> location to be in line with the other architectures.
>>>
>>> Please have a look and give some comments!
>>
>> Looks good to me, but I'd like to see some comments from some mips/ppc/x86
>> people on the changes you're making over there.
> 
> Looks mostly good to me, as one of the kvmtool down streams. Over at
> https://github.com/clearlinux/kvmtool we have some patches to tweak
> the x86 boot flow, which will need rebasing/retweaking) specifically
> this commit here -
> https://github.com/clearlinux/kvmtool/commit/a8dee709f85735d16739d0eda0cc00d3c1b17477

Awesome - I was actually thinking about coding something like this!
In the last week I move the MIPS ELF loading out of mips/ into /elf.c to
be able to load kvm-unit-tests' tests (which are Multiboot/ELF). As
multiboot requires entering in protected mode, I was thinking about
changing kvmtool to support entering a guest directly in protected mode
- seems like this is mostly what you've done here already.

Looks like we should both post our patches to merge them somehow ;-)

Cheers,
Andre.

  reply	other threads:[~2015-11-02 16:03 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30 18:26 [PATCH 0/7] kvmtool: Cleanup kernel loading Andre Przywara
2015-10-30 18:26 ` Andre Przywara
2015-10-30 18:26 ` Andre Przywara
2015-10-30 18:26 ` [PATCH 1/7] Refactor kernel image loading Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26 ` [PATCH 2/7] provide generic read_file() implementation Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26 ` [PATCH 3/7] powerpc: use read_file() in kernel and initrd loading Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26 ` [PATCH 4/7] MIPS: use read wrappers in kernel loading Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26 ` [PATCH 5/7] x86: " Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26 ` [PATCH 6/7] arm/arm64: use read_file() in kernel and initrd loading Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:26   ` Andre Przywara
2015-10-30 18:27 ` [PATCH 7/7] arm: move kernel loading into arm/kvm.c Andre Przywara
2015-10-30 18:27   ` Andre Przywara
2015-10-30 18:27   ` Andre Przywara
2015-11-02 14:58 ` [PATCH 0/7] kvmtool: Cleanup kernel loading Will Deacon
2015-11-02 14:58   ` Will Deacon
2015-11-02 14:58   ` Will Deacon
2015-11-02 15:17   ` Dimitri John Ledkov
2015-11-02 15:17     ` Dimitri John Ledkov
2015-11-02 15:17     ` Dimitri John Ledkov
2015-11-02 16:03     ` Andre Przywara [this message]
2015-11-02 16:03       ` Andre Przywara
2015-11-02 16:03       ` Andre Przywara
2015-11-18 10:29   ` Andre Przywara
2015-11-18 10:29     ` Andre Przywara
2015-11-18 17:08     ` Will Deacon
2015-11-18 17:08       ` Will Deacon

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=56378937.8050504@arm.com \
    --to=andre.przywara@arm.com \
    --cc=dimitri.j.ledkov@intel.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.