On Wed, Jan 27, 2021 at 04:49:11PM +0800, Cao jin wrote:
> struct setup_data.len is the length of data field. In case of
> SETUP_INDIRECT, it should be sizeof(setup_indirect).
>
> Signed-off-by: Cao jin
Reviewed-by: Daniel Kiper
Daniel
Hey,
This is next attempt to create firmware and bootloader log specification.
Due to high interest among industry it is an extension to the initial
bootloader log only specification. It takes into the account most of the
comments which I got up until now.
The goal is to pass all logs produced by
On Mon, Oct 19, 2020 at 01:18:22PM -0400, Arvind Sankar wrote:
> On Mon, Oct 19, 2020 at 04:51:53PM +0200, Daniel Kiper wrote:
> > On Fri, Oct 16, 2020 at 04:51:51PM -0400, Arvind Sankar wrote:
> > > On Thu, Oct 15, 2020 at 08:26:54PM +0200, Daniel Kiper wrote:
> > > >
On Fri, Oct 16, 2020 at 04:51:51PM -0400, Arvind Sankar wrote:
> On Thu, Oct 15, 2020 at 08:26:54PM +0200, Daniel Kiper wrote:
> >
> > I am discussing with Ross the other option. We can create
> > .rodata.mle_header section and put it at fixed offset as
> > kernel_info
On Tue, Sep 29, 2020 at 10:03:47AM -0400, Ross Philipson wrote:
> On 9/25/20 3:18 PM, Arvind Sankar wrote:
[...]
> > You should see them if you do
> > readelf -r arch/x86/boot/compressed/vmlinux
> >
> > In terms of the code, things like:
> >
> > addl%ebx, (sl_gdt_desc + 2)(%ebx)
> >
>
On Fri, May 29, 2020 at 10:11:40AM -0700, Andy Lutomirski wrote:
> > On May 29, 2020, at 4:30 AM, Daniel Kiper wrote:
> >
> > Hey,
> >
> > Below you can find my rough idea of the bootloader log format which is
> > generic thing but initially will be used for T
Hey,
Below you can find my rough idea of the bootloader log format which is
generic thing but initially will be used for TrenchBoot work. I discussed
this proposal with Ross and Daniel S. So, the idea went through initial
sanitization. Now I would like to take feedback from other folks too.
So, pl
Hi Łukasz,
On Tue, May 05, 2020 at 04:38:02PM +0200, Lukasz Hawrylko wrote:
> On Tue, 2020-05-05 at 01:21 +0200, Daniel Kiper wrote:
> > Hi,
> >
> > This is an RFC patchset for the GRUB introducing the Intel TXT secure
> > launcher.
> > This is a part of la
On Wed, May 06, 2020 at 11:36:49AM -0700, Matthew Garrett wrote:
> On Wed, May 6, 2020 at 6:33 AM Daniel Kiper wrote:
> >
> > On Tue, May 05, 2020 at 10:29:05AM -0700, Matthew Garrett wrote:
> > > On Mon, May 4, 2020 at 4:25 PM Daniel Kiper
> > > wrote:
> >
On Tue, May 05, 2020 at 10:29:05AM -0700, Matthew Garrett wrote:
> On Mon, May 4, 2020 at 4:25 PM Daniel Kiper wrote:
> >
> > Otherwise the kernel does not know its state and cannot enable various
> > security features depending on UEFI Secure Boot.
>
> I think this
From: Ross Philipson
Signed-off-by: Ross Philipson
Signed-off-by: Daniel Kiper
---
grub-core/loader/i386/txt/txt.c | 887
include/grub/i386/memory.h | 5 +
2 files changed, 892 insertions(+)
create mode 100644 grub-core/loader/i386/txt/txt.c
Otherwise the kernel does not know its state and cannot enable various
security features depending on UEFI Secure Boot.
Signed-off-by: Ignat Korchagin
Signed-off-by: Daniel Kiper
---
grub-core/loader/i386/linux.c | 86 ++-
include/grub/i386/linux.h
It will be used by Intel TXT secure launcher introduced
by subsequent patches.
Signed-off-by: Daniel Kiper
---
grub-core/commands/i386/tpm.c | 182 ++
include/grub/i386/tpm.h | 36 +
2 files changed, 218 insertions(+)
create mode 100644
..to avoid naming collision with TPM TIS and CRB driver introduced
by subsequent patch.
Signed-off-by: Daniel Kiper
---
docs/grub.texi | 15 ---
grub-core/Makefile.core.def | 4 ++--
grub-core/commands/{tpm.c => tpm_verifier.c} |
.. to grub_rdmsr() and grub_wrmsr() respectively. New names are more
obvious than older ones.
Signed-off-by: Daniel Kiper
---
grub-core/commands/i386/rdmsr.c | 2 +-
grub-core/commands/i386/wrmsr.c | 2 +-
include/grub/i386/msr.h | 4 ++--
3 files changed, 4 insertions(+), 4 deletions
From: Ross Philipson
Signed-off-by: Ross Philipson
Signed-off-by: Daniel Kiper
---
include/grub/i386/txt.h | 690
1 file changed, 690 insertions(+)
create mode 100644 include/grub/i386/txt.h
diff --git a/include/grub/i386/txt.h b/include/grub
From: Ross Philipson
Signed-off-by: Ross Philipson
Signed-off-by: Daniel Kiper
---
grub-core/loader/i386/txt/acmod.c | 575 ++
1 file changed, 575 insertions(+)
create mode 100644 grub-core/loader/i386/txt/acmod.c
diff --git a/grub-core/loader/i386/txt
From: Ross Philipson
Signed-off-by: Ross Philipson
Signed-off-by: Daniel Kiper
---
grub-core/Makefile.am| 3 +
grub-core/Makefile.core.def | 15 +++
grub-core/lib/i386/relocator32.S | 8 ++
grub-core/loader/i386/bsd.c | 7 ++
grub-core/loader/i386/linux.c| 206
The functions calculate lowest and highest available RAM
addresses respectively.
Both functions are needed to calculate PMR boundaries for
Intel TXT secure launcher introduced by subsequent patches.
Signed-off-by: Daniel Kiper
---
grub-core/mmap/mmap.c | 64
From: Ross Philipson
Signed-off-by: Ross Philipson
Signed-off-by: Daniel Kiper
---
include/grub/i386/cpuid.h | 13
include/grub/i386/crfr.h | 186 ++
include/grub/i386/mmio.h | 90 ++
include/grub/i386/msr.h | 61
It will be used to properly detect and report UEFI Secure Boot status to
the x86 Linux kernel. The functionality will be added by subsequent patches.
Signed-off-by: Ignat Korchagin
Signed-off-by: Daniel Kiper
---
grub-core/kern/efi/efi.c | 16 +---
include/grub/efi/efi.h | 5
From: Ross Philipson
Signed-off-by: Ross Philipson
Signed-off-by: Daniel Kiper
---
grub-core/loader/i386/txt/verify.c | 297 +
1 file changed, 297 insertions(+)
create mode 100644 grub-core/loader/i386/txt/verify.c
diff --git a/grub-core/loader/i386/txt
This is needed to properly detect and report UEFI Secure Boot status
to the x86 Linux kernel. The functionality will be added by subsequent
patches.
Signed-off-by: Daniel Kiper
---
grub-core/commands/efi/efifwsetup.c | 8
grub-core/kern/efi/efi.c| 16 +---
grub
Hi,
This is an RFC patchset for the GRUB introducing the Intel TXT secure launcher.
This is a part of larger work known as the TrenchBoot. Patchset can be split
into two distinct parts:
- 01-12: preparatory patches,
- 13-18: the Intel TXT secure launcher itself.
The initial implementation of
It does not make sense to have separate headers for separate static
functions. Additionally, we have to add some constants with MSR addresses
in subsequent patches. So, make one common place to store them.
Signed-off-by: Daniel Kiper
---
grub-core/commands/i386/rdmsr.c | 2 +-
grub-core
Subsequent patches will use that constant.
Signed-off-by: Daniel Kiper
---
grub-core/loader/i386/xen.c | 35 +--
include/grub/i386/memory.h | 1 +
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader
..to avoid potential conflicts and confusion.
Signed-off-by: Daniel Kiper
---
grub-core/lib/i386/xen/relocator.S | 6 +++---
grub-core/lib/x86_64/xen/relocator.S | 4 ++--
grub-core/loader/i386/xen.c | 28 ++--
include/grub/i386/memory.h | 2 +-
4
The GUID will be used to properly detect and report UEFI Secure Boot
status to the x86 Linux kernel. The functionality will be added by
subsequent patches. The shim_lock protocol type is made public for
completeness.
Additionally, fix formatting of four preceding GUIDs.
Signed-off-by: Daniel
GRUB_ERR_BAD_DEVICE instead of GRUB_ERR_BUG to signal
an error because errors encountered by this new routine are not bugs.
Signed-off-by: Daniel Kiper
---
grub-core/commands/i386/rdmsr.c | 21 +
grub-core/commands/i386/wrmsr.c | 21 +
include/grub/i386/msr.h | 29
On Tue, Oct 01, 2019 at 03:28:01PM -0700, H. Peter Anvin wrote:
> On 2019-10-01 04:41, Daniel Kiper wrote:
> >
> > OK, so, this is more or less what I had in my v3 patch before sending
> > this email. So, it looks that I am on good track. Great! Though I am not
> > sur
I am working on new version of patches but I have some concerns. Please
look below for more details...
On Thu, Jun 06, 2019 at 03:06:30PM -0700, H. Peter Anvin wrote:
> On 5/24/19 2:55 AM, Daniel Kiper wrote:
> > Due to limited space left in the setup header it was decided to
> >
On Thu, Jun 06, 2019 at 01:30:46PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 06, 2019 at 01:51:08PM +0200, Daniel Kiper wrote:
> > On Wed, Jun 05, 2019 at 10:01:17AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jun 05, 2019 at 03:50:31PM +0200, Daniel Kiper wrote:
&
On Wed, Jun 05, 2019 at 10:01:17AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 05, 2019 at 03:50:31PM +0200, Daniel Kiper wrote:
> > On Fri, May 24, 2019 at 11:55:02AM +0200, Daniel Kiper wrote:
> > > Hi,
> > >
> > > This change is needed to properly
On Fri, May 24, 2019 at 11:55:02AM +0200, Daniel Kiper wrote:
> Hi,
>
> This change is needed to properly start the Linux kernel in Intel TXT mode and
> is a part of the TrenchBoot project (https://github.com/TrenchBoot).
>
> Daniel
>
> Documentation/x86/boo
-by: Daniel Kiper
Reviewed-by: Ross Philipson
Reviewed-by: Eric Snowberg
---
I know that setup_header2 is not the best name. There were some
alternatives proposed like setup_header_extra, setup_header_addendum,
setup_header_more, ext_setup_header, extended_setup_header, extended_header
and
| 3 ++-
arch/x86/boot/tools/build.c | 8
arch/x86/include/uapi/asm/bootparam.h| 1 +
9 files changed, 123 insertions(+), 4 deletions(-)
Daniel Kiper (2):
x86/boot: Introduce the setup_header2
x86/boot: Introduce dummy MLE header
DO NOT APPLY!!!
THIS PATCH INTRODUCES DUMMY MLE HEADER AND SIMPLY ILLUSTRATES HOW TO
EXTEND THE setup_header2 PROPERLY.
DO NOT APPLY!!!
Signed-off-by: Ross Philipson
Signed-off-by: Daniel Kiper
Reviewed-by: Ross Philipson
---
Documentation/x86/boot.txt | 6 ++
arch/x86
On Thu, Mar 28, 2019 at 11:15:53AM -0700, H. Peter Anvin wrote:
> So, per our conversation today, lets create a new, readonly, data structure
> pointed to by a single field in setup_header, in order to preserve what little
> space we have left in that structure (a whopping 24 bytes...)
>
> The new
On Fri, Mar 08, 2019 at 12:43:10PM +0100, Juergen Gross wrote:
> Documentation/x86/boot.txt is missing protocol 2.13 description.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
Daniel
Commit-ID: a7012bdbdf406bbaa4e3de0cc3d8eb0faaacbf93
Gitweb: https://git.kernel.org/tip/a7012bdbdf406bbaa4e3de0cc3d8eb0faaacbf93
Author: Daniel Kiper
AuthorDate: Fri, 4 May 2018 07:59:47 +0200
Committer: Ingo Molnar
CommitDate: Mon, 14 May 2018 08:57:46 +0200
x86/xen/efi: Initialize
On Mon, Apr 16, 2018 at 10:15:15AM +0200, Ard Biesheuvel wrote:
> On 11 April 2018 at 10:56, Daniel Kiper wrote:
> > On Wed, Apr 04, 2018 at 12:38:24PM +0200, Daniel Kiper wrote:
> >> On Tue, Apr 03, 2018 at 10:00:52AM -0700, James Bottomley wrote:
> >> > On Tue, 201
On Wed, Apr 04, 2018 at 12:38:24PM +0200, Daniel Kiper wrote:
> On Tue, Apr 03, 2018 at 10:00:52AM -0700, James Bottomley wrote:
> > On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote:
> > > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote:
>
> [...]
>
On Tue, Apr 03, 2018 at 10:00:52AM -0700, James Bottomley wrote:
> On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote:
> > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote:
[...]
> > > This looks like a bad idea: you're duplicating the sec
On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote:
> On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote:
> > Initialize UEFI secure boot state during dom0 boot. Otherwise the
> > kernel
> > may not even know that it runs on secure boot enabled platform.
Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
may not even know that it runs on secure boot enabled platform.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/efi.c| 57 +
drivers/firmware/efi/libstub/secureboot.c
> > do the restoration manually on vmentry but let it be automatic on
> > vmexit, by having it *only* in the guest's MSR-store area to be saved
> > on exit and restored on exit, but *not* in the host's MSR-store area?
s/on exit and restored on exit/on exit and r
Hi Ard,
On Thu, Jan 11, 2018 at 12:51:07PM +, Ard Biesheuvel wrote:
> On 9 January 2018 at 14:22, Daniel Kiper wrote:
> > Hi,
> >
> > Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
> > may not even know that it runs on secure boot enab
code. Subsequent patch
will add efi_get_secureboot() call from Xen dom0 boot code.
There is no functional change.
Signed-off-by: Daniel Kiper
---
drivers/firmware/efi/libstub/secureboot-core.c | 77
drivers/firmware/efi/libstub/secureboot.c | 66
Otherwise the kernel reports incorrect UEFI secure boot state in the Xen dom0.
By the way fix CFLAGS_mmu_pv.o assignment alignment.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/Makefile |4 +++-
arch/x86/xen/efi.c| 11 +++
2 files changed, 14 insertions(+), 1 deletion
Otherwise they are not freed after the kernel proper init.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/efi.c |3 +++
drivers/firmware/efi/libstub/secureboot-core.c | 12 ++--
drivers/firmware/efi/libstub/secureboot.c |3 +++
3 files changed
/efi/libstub/secureboot-core.c | 77
+
drivers/firmware/efi/libstub/secureboot.c | 66
+--
4 files changed, 99 insertions(+), 62 deletions(-)
Daniel Kiper (4
This may help compiler to do some function call optimization.
This is rather cosmetic. If you like this patch apply.
If you do not you may ignore it.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/efi.c |2 +-
drivers/firmware/efi/libstub/secureboot-core.c |2
On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah
On Wed, Jul 19, 2017 at 01:19:58PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:
On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > Hey Greg,
> >
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch. If anyone has
Hey Greg,
On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> 4.12-stable review patch. If anyone has any objections, please let me know.
Why did you skip this patch for 4.11? IMO it should be applied there too.
Daniel
Commit-ID: 6c64447ec58b0bac612732303f7ab04562124587
Gitweb: http://git.kernel.org/tip/6c64447ec58b0bac612732303f7ab04562124587
Author: Daniel Kiper
AuthorDate: Thu, 22 Jun 2017 12:51:37 +0200
Committer: Ingo Molnar
CommitDate: Fri, 23 Jun 2017 11:11:03 +0200
x86/xen/efi: Initialize
Commit-ID: 457ea3f7e97881f937136ce0ba1f29f82b9abdb0
Gitweb: http://git.kernel.org/tip/457ea3f7e97881f937136ce0ba1f29f82b9abdb0
Author: Daniel Kiper
AuthorDate: Thu, 22 Jun 2017 12:51:36 +0200
Committer: Ingo Molnar
CommitDate: Fri, 23 Jun 2017 11:11:02 +0200
efi: Process the MEMATTR
mbers used by
Xen to avoid such issues in the future.
Signed-off-by: Daniel Kiper
Acked-by: Ard Biesheuvel
--
Align assignments to increase readability. Suggested by Ingo Molnar.
---
arch/x86/xen/efi.c | 45 -
1 file changed, 12 insertions(+), 33 dele
Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more generic and covers more cases.
Signed-off-by: Daniel Kiper
Reviewed-by: Ard Biesheuvel
---
drivers/firmware/efi/efi.c |3 ++-
1 file changed, 2 insertions(+), 1
-
drivers/firmware/efi/efi.c |3 ++-
2 files changed, 14 insertions(+), 34 deletions(-)
Daniel Kiper (2):
efi: Process MEMATTR table only if EFI_MEMMAP
x86/xen/efi: Init only efi struct members used by Xen
On Wed, Jun 21, 2017 at 11:24:06AM +0200, Ingo Molnar wrote:
>
> * Daniel Kiper wrote:
>
> > -static const struct efi efi_xen __initconst = {
> > - .systab = NULL, /* Initialized later. */
> > - .runtime_version = 0,/* Initial
On Wed, Jun 21, 2017 at 09:10:51AM +0100, Andrew Cooper wrote:
> On 20/06/2017 21:14, Daniel Kiper wrote:
> > Current approach, wholesale efi struct initialization from efi_xen, is not
> > good. Usually if new member is defined then it is properly initialized in
> > drivers/f
mbers used by
Xen to avoid such issues in the future.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/efi.c | 45 -
1 file changed, 12 insertions(+), 33 deletions(-)
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 30bb2e8..01b9faf 100644
--- a
Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more generic and covers more cases.
Signed-off-by: Daniel Kiper
---
drivers/firmware/efi/efi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
insertions(+), 34 deletions(-)
Daniel Kiper (2):
efi: Process MEMATTR table only if EFI_MEMMAP
x86/xen/efi: Init only efi struct members used by Xen
On Wed, Apr 19, 2017 at 08:37:38PM +0100, Matt Fleming wrote:
> On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote:
> > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote:
> > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
> > > >
> > >
On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote:
> On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
> >
> > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper,
> > rather than spreading it further.
> >
> > IMO, given reset_system is a *mandatory* function, the Xe
On Fri, Apr 14, 2017 at 06:53:36PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 19:20:08 +0200
> Daniel Kiper wrote:
> > On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> >[...]
> > > Tested-by: Petr Tesarik
> > >
> > > I copied the
On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 15:00:58 +0200
> Daniel Kiper wrote:
>
> > On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > > On 03/04/17 14:42, Daniel Kiper wrote:
> > > > On Fri, Mar 3
On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> On 03/04/17 14:42, Daniel Kiper wrote:
> > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> >> For kdump to work correctly it needs the physical address of
> >> vmcoreinfo_note. When run
On Fri, Apr 07, 2017 at 11:16:22AM +0200, Petr Tesarik wrote:
> On Wed, 5 Apr 2017 13:13:00 +0200
> Petr Tesarik wrote:
>
> > On Tue, 4 Apr 2017 12:42:53 -0700 (PDT)
> > Daniel Kiper wrote:
> >
> >[...]
> > > So, if Petr did relevant tests that is nice.
On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:
> On 06/04/17 18:06, Daniel Kiper wrote:
> > Hi Julien,
> >
> > On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
> >> Hi Daniel,
> >>
> >> On 06/04/17 16:20, Daniel Kiper
Hi Julien,
On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
> Hi Daniel,
>
> On 06/04/17 16:20, Daniel Kiper wrote:
> >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:
> >>On 06/04/17 16:27, Daniel Kiper wrote:
> >>>On Thu, Apr 06, 20
On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:
> On 06/04/17 16:27, Daniel Kiper wrote:
> > On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote:
> >> Hi Juergen,
> >>
> >> On 06/04/17 07:23, Juergen Gross wrote:
> >>> On 05/
On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote:
> Hi Juergen,
>
> On 06/04/17 07:23, Juergen Gross wrote:
> >On 05/04/17 21:49, Boris Ostrovsky wrote:
> >>On 04/05/2017 02:14 PM, Julien Grall wrote:
> >>>The x86 code has theoritically a similar issue, altought EFI does not
> >>>seem t
> On 03/04/17 14:42, Daniel Kiper wrote:
> > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> >> For kdump to work correctly it needs the physical address of
> >> vmcoreinfo_note. When running as dom0 this means the virtual address
> >> has to
ast basic commands
like dmesg, bt, ps, etc.)? If yes for both you can add:
Reviewed-by: Daniel Kiper
Daniel
Hey,
On Mon, Mar 06, 2017 at 03:54:17PM +0100, Michal Hocko wrote:
[...]
> So let's discuss the current memory hotplug shortcomings and get rid of
> the crud which developed on top. I will start by splitting up the patch
> into 3 parts. Do the auto online thing from the HyperV and xen balloning
On Thu, Feb 16, 2017 at 09:00:05PM -0800, H. Peter Anvin wrote:
> On 02/16/17 15:27, Daniel Kiper wrote:
> > That is obvious. Do you think that Multiboot/Multiboot2 protocols are
> > substantially suboptimal?
>
> Yes. They push a lot of things into the bootloader for no goo
On Wed, Feb 15, 2017 at 12:58:37PM -0800, h...@zytor.com wrote:
[...]
> Multiboot has a fundamentally broken assumption, which is to do certain work
Just to be precise. We are talking about Multiboot2 here.
> for the kernel in the bootloader. This is fundamentally a bad idea, because
Why it is
On Tue, May 24, 2016 at 09:54:31AM -0500, Tom Lendacky wrote:
> On 05/12/2016 01:20 PM, Tom Lendacky wrote:
> > On 05/10/2016 08:57 AM, Borislav Petkov wrote:
> >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote:
> >>> Is it not possible to maintain some kind of kernel virtual address
On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote:
> Boris sent out the first HVMLite series of patches to add a new Xen guest type
> February 1, 2016 [0]. We've been talking off list with a few folks now over
> the prospect of instead of adding yet-another-boot-entry we instead fix
On Wed, Feb 17, 2016 at 03:27:01PM +0100, Juergen Gross wrote:
> On 17/02/16 14:59, Daniel Kiper wrote:
> > On Tue, Feb 16, 2016 at 01:55:33PM +0100, Juergen Gross wrote:
> >> Hi Daniel,
> >>
> >> On 16/02/16 12:35, Daniel Kiper wrote:
> >>> H
On Tue, Feb 16, 2016 at 01:55:33PM +0100, Juergen Gross wrote:
> Hi Daniel,
>
> On 16/02/16 12:35, Daniel Kiper wrote:
> > Hey Juergen,
[...]
> > After that I decided to take a look at Linux kernel upstream. I saw
> > that xen_max_p2m_pfn in xen_build_mfn_list_list()
Hey Juergen,
As I saw you are strongly playing with p2m stuff, so,
I hope that you can enlighten me a bit in that area.
OVM, Oracle product, uses as dom0 kernel Linux 3.8.13
(yep, I know this is very ancient stuff) with a lot of
backports. Among them there is commit 2c185687ab016954557aac80074f5d
On Tue, Feb 02, 2016 at 01:15:13PM +, Li, Liang Z wrote:
> > >> We found dom0 will crash when booing on HSW-EX server, the dom0
> > >> kernel version is v4.4. By debugging I found the your patch '
> > >> x86/xen: discard RAM regions above the maximum reservation' , which
> > the commit ID is :
On Fri, Jan 22, 2016 at 10:03:34AM +, David Vrabel wrote:
> On 21/01/16 20:13, Daniel Kiper wrote:
> > Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8
> > (xen: switch to linear virtual mapped sparse p2m list), which
> > appeared in 3.19, introduced linear
crash_xen_info_t.dom0_pfn_to_mfn_frame_list_list
which is available out of the box. So, let's use it and make
at least some users happy.
Signed-off-by: Daniel Kiper
---
kernel.c | 81 ++--
xen_dom0.c |3 ++-
xen_dom0.h |2 ++
3 files change
ble
> values: "offline" (the default) which preserves the current behavior and
> "online" which causes all newly added memory blocks to go online as
> soon as they're added.
In general idea make sense for me but...
> Cc: Jonathan Corbet
> Cc: Greg Kroah-Hartm
Follow similar x86 patch.
Signed-off-by: Daniel Kiper
---
kexec/arch/arm/crashdump-arm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index b523e5f..b3e93ad 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b
Signed-off-by: Daniel Kiper
---
kexec/crashdump.h |1 -
1 file changed, 1 deletion(-)
diff --git a/kexec/crashdump.h b/kexec/crashdump.h
index 95f1f0c..320767b 100644
--- a/kexec/crashdump.h
+++ b/kexec/crashdump.h
@@ -1,7 +1,6 @@
#ifndef CRASHDUMP_H
#define CRASHDUMP_H
-int
Signed-off-by: Daniel Kiper
---
kexec/kexec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kexec/kexec.c b/kexec/kexec.c
index f0bd527..20dd93d 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -969,7 +969,7 @@ void usage(void
Provide just print_crashkernel_region_size() stub. This way
we can properly build kexec utility on cris arch even
if the functionality is not available on it.
Signed-off-by: Daniel Kiper
---
kexec/arch/cris/kexec-cris.c |5 +
1 file changed, 5 insertions(+)
diff --git a/kexec/arch/cris
Signed-off-by: Daniel Kiper
---
purgatory/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/purgatory/Makefile b/purgatory/Makefile
index 2b5c061..caea7ea 100644
--- a/purgatory/Makefile
+++ b/purgatory/Makefile
@@ -33,7 +33,7 @@ PURGATORY_SRCS+=$($(ARCH
Signed-off-by: Daniel Kiper
---
kexec/arch/i386/crashdump-x86.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index bbc0f35..10a56a8 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/
, 98 insertions(+), 5 deletions(-)
Daniel Kiper (14):
purgatory: Add purgatory.map and purgatory.ro.sym to clean recipe
kexec: Remove redundant space from help message
crashdump: Remove stray get_crashkernel_region() declaration
crashdump/x86: Add print_crashkernel_region_
Provide just print_crashkernel_region_size() stub. This way
we can properly build kexec utility on m68k arch even
if the functionality is not available on it.
Signed-off-by: Daniel Kiper
---
kexec/arch/m68k/kexec-m68k.c |5 +
1 file changed, 5 insertions(+)
diff --git a/kexec/arch/m68k
Provide just print_crashkernel_region_size() stub. This way
we can properly build kexec utility on ppc arch even
if the functionality is not available on it.
Signed-off-by: Daniel Kiper
---
kexec/arch/ppc/crashdump-powerpc.c |4
1 file changed, 4 insertions(+)
diff --git a/kexec/arch
Follow similar x86 patch.
Signed-off-by: Daniel Kiper
---
kexec/arch/ia64/crashdump-ia64.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/kexec/arch/ia64/crashdump-ia64.c b/kexec/arch/ia64/crashdump-ia64.c
index 726c9f4..07de42a 100644
--- a/kexec/arch/ia64/crashdump-ia64.c
1 - 100 of 323 matches
Mail list logo
