date:20211129

Re: grub2 + xen + lz4 kernels

2021-11-29 Thread Juergen Gross via Grub-devel


On 30.11.21 00:25, Shaun Reitan wrote:
I currently use XEN to boot PV (paravirt) virtual server instances for 
our customers. Grub2 introduced support for booting a xen kernel 
directly from a guests disk image which has worked great for years. We 
use the following command to build our image


grub-mkstandalone -O x86_64-xen -o grub2-x86_64.gz boot/grub/grub.cfg

What we have been seeing more and more is newer distros like Ubuntu 
20.04 using lz4 compressed kernel images which will not boot and 
displays the error "not xen image."


If i use the 
https://raw.githubusercontent.com/torvalds/linux/master/scripts/extract-vmlinux 
 utility 
to decompress the kernel image I am able to boot it without any issues 
using our current grub2 xen loader.


My question is how can I get lz4 support added into grub2 for xen? We 
are willing to pay for a dev to add this support if needed as I have 
limited time to really dig into this.


There are a few workarounds out their, most involve a hook that 
decompresses the kernel after an update but I'm not wanting to add 
complexity to the kernel update process. It leaves too much room for 
error and the possibility of a clients server failing to boot after what 
should of been a simple kernel upgrade.


Any help, even if just pointing me in the right direction would be 
appreciated!


Hmm, Grub2 already supports some compression methods, so adding LZ4
shouldn't be that hard. Especially as there already is some LZ4
support hidden in the ZFS handling.

I guess this LZ4 support wants to be put into a grub module of its
own and then be added to the filter list.

You should have a look at:

- GRUB_FILE_FILTER_GZIO for an example how a compression filter is
  added via grub_file_filter_register()

- the file grub-core/fs/zfs/zfs_lz4.c for current LZ4 support in
  Grub2

This should basically do the job.

I've added Daniel to Cc: as he might have some more thoughts.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub2 + xen + lz4 kernels

2021-11-29 Thread Andy Smith

Hi Shaun,

On Mon, Nov 29, 2021 at 11:25:22PM +, Shaun Reitan wrote:
> There are a few workarounds out their, most involve a hook that decompresses
> the kernel after an update but I'm not wanting to add complexity to the
> kernel update process.

Another option is to switch the guest to Xen PVH mode. The Grub2 PVH
image can boot LZ4-compressed kernels and all versions of Ubuntu
that use LZ4 kernels also support booting as a PVH mode guest
without any change to the guest.

grub-mkimage -O i386-xenpvh -o /opt/grub/lib/pvhgrub.bin …

I am not sure that you will find anyone to work on Xen PV support
any more as I think Xen upstream would rather see you move to PVH.

Cheers,
Andy

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

grub2 + xen + lz4 kernels

2021-11-29 Thread Shaun Reitan

I currently use XEN to boot PV (paravirt) virtual server instances for 
our customers. Grub2 introduced support for booting a xen kernel 
directly from a guests disk image which has worked great for years. We 
use the following command to build our image


grub-mkstandalone -O x86_64-xen -o grub2-x86_64.gz boot/grub/grub.cfg

What we have been seeing more and more is newer distros like Ubuntu 
20.04 using lz4 compressed kernel images which will not boot and 
displays the error "not xen image."


If i use the 
https://raw.githubusercontent.com/torvalds/linux/master/scripts/extract-vmlinux 
utility to decompress the kernel image I am able to boot it without any 
issues using our current grub2 xen loader.


My question is how can I get lz4 support added into grub2 for xen? We 
are willing to pay for a dev to add this support if needed as I have 
limited time to really dig into this.


There are a few workarounds out their, most involve a hook that 
decompresses the kernel after an update but I'm not wanting to add 
complexity to the kernel update process. It leaves too much room for 
error and the possibility of a clients server failing to boot after what 
should of been a simple kernel upgrade.


Any help, even if just pointing me in the right direction would be 
appreciated!


--
Shaun Reitan
NDCHost.com
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Drop gnulib fix-base64.patch

2021-11-29 Thread Robbie Harwood

Daniel Kiper  writes:

> Yeah, but I think it would require major overhaul. Does not it? If yes
> then maybe we should consider move to the Kconfig or something like
> that.

Perhaps, but please don't mistake me as volunteering for build system
hacking - I'm mostly just here to upstream patches :)

In the end, I submit that you as the upstream maintainer have should
something you can work with and solve problems in.  If what's there
isn't that, then something needs to change in order for things to get
better - and maybe a major overhaul would be worth it.

Be well,
--Robbie

signature.asc
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 2/2] Make a "gdb" dprintf that tells us load addresses

2021-11-29 Thread Robbie Harwood

Daniel Kiper  writes:

> On Wed, Nov 03, 2021 at 02:22:07PM -0400, Robbie Harwood wrote:
>> From: Peter Jones 
>>
>> Add a grub_dprintf() call during platform init and during module loading
>> that tells us the virtual addresses of the .text and .data sections of
>> grub-core/kernel.exec and any modules it loads.
>>
>> Specifically, it displays them in the gdb "add-symbol-file" syntax, with
>> the presumption that there's a variable $grubdir that reflects the path
>> to any such binaries.
>
> Could you tell us why this thing has to be displayed as a part of debug
> messages? Could you create a separate command which would do the same?

I don't follow what you're suggesting.  It's debug output and gdb is a
debugger.  What would you have it do instead?

Be well,
--Robbie


signature.asc
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH v2 1/2] efinet: correct closing of SNP protocol

2021-11-29 Thread Heinrich Schuchardt

In the context of the implementation of the EFI_LOAD_FILE2_PROTOCOL for
the initial ramdisk it was observed that opening the SNP protocol failed.
https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00020.html
This is due to an incorrect call to CloseProtocol().

The first parameter of CloseProtocol() is the handle, not the interface.

We call OpenProtocol() with ControllerHandle = NULL. Hence we must also
call CloseProtcol with ControllerHandel = NULL.

Each call of OpenProtocol() for the same network card handle is expected to
return the same interface pointer. If we want to close the protocol which
we opened non-exclusively when searching for a card, we have to do this
before opening the protocol exclusively.

As there is no guarantee that we successfully open the protocol add checks
in the transmit and receive functions.

Reported-by: Andreas Schwab 
Signed-off-by: Heinrich Schuchardt 
---
v2:
do not open SNP protocol non-exclusively
adjust code style
---
 grub-core/net/drivers/efi/efinet.c | 31 +-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/grub-core/net/drivers/efi/efinet.c 
b/grub-core/net/drivers/efi/efinet.c
index 5388f952b..bcd812ff5 100644
--- a/grub-core/net/drivers/efi/efinet.c
+++ b/grub-core/net/drivers/efi/efinet.c
@@ -39,6 +39,9 @@ send_card_buffer (struct grub_net_card *dev,
   grub_uint64_t limit_time = grub_get_time_ms () + 4000;
   void *txbuf;
 
+  if (net == NULL)
+return grub_error (GRUB_ERR_IO,
+  N_("network protocol not available, can't send packet"));
   if (dev->txbusy)
 while (1)
   {
@@ -101,6 +104,9 @@ get_card_packet (struct grub_net_card *dev)
   struct grub_net_buff *nb;
   int i;
 
+  if (net == NULL)
+return NULL;
+
   for (i = 0; i < 2; i++)
 {
   if (!dev->rcvbuf)
@@ -148,12 +154,20 @@ open_card (struct grub_net_card *dev)
 {
   grub_efi_simple_network_t *net;
 
-  /* Try to reopen SNP exlusively to close any active MNP protocol instance
- that may compete for packet polling
+  if (dev->efi_net != NULL)
+{
+  efi_call_4 (grub_efi_system_table->boot_services->close_protocol,
+ dev->efi_handle, _io_guid,
+ grub_efi_image_handle, NULL);
+  dev->efi_net = NULL;
+}
+  /*
+   * Try to reopen SNP exlusively to close any active MNP protocol instance
+   * that may compete for packet polling
*/
   net = grub_efi_open_protocol (dev->efi_handle, _io_guid,
GRUB_EFI_OPEN_PROTOCOL_BY_EXCLUSIVE);
-  if (net)
+  if (net != NULL)
 {
   if (net->mode->state == GRUB_EFI_NETWORK_STOPPED
  && efi_call_1 (net->start, net) != GRUB_EFI_SUCCESS)
@@ -192,13 +206,12 @@ open_card (struct grub_net_card *dev)
  efi_call_6 (net->receive_filters, net, filters, 0, 0, 0, NULL);
}
 
-  efi_call_4 (grub_efi_system_table->boot_services->close_protocol,
- dev->efi_net, _io_guid,
- grub_efi_image_handle, dev->efi_handle);
   dev->efi_net = net;
+} else {
+  return grub_error (GRUB_ERR_NET_NO_CARD, "%s: can't open protocol",
+dev->name);
 }
 
-  /* If it failed we just try to run as best as we can */
   return GRUB_ERR_NONE;
 }
 
@@ -208,8 +221,8 @@ close_card (struct grub_net_card *dev)
   efi_call_1 (dev->efi_net->shutdown, dev->efi_net);
   efi_call_1 (dev->efi_net->stop, dev->efi_net);
   efi_call_4 (grub_efi_system_table->boot_services->close_protocol,
- dev->efi_net, _io_guid,
- grub_efi_image_handle, dev->efi_handle);
+ dev->efi_handle, _io_guid,
+ grub_efi_image_handle, 0);
 }
 
 static struct grub_net_card_driver efidriver =
-- 
2.32.0


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH v2 2/2] efi: library function grub_efi_close_protocol()

2021-11-29 Thread Heinrich Schuchardt

Create a library function for CloseProtocol() and use it for the SNP
driver.

Signed-off-by: Heinrich Schuchardt 
---
v2:
adjust code style
---
 grub-core/kern/efi/efi.c   | 12 
 grub-core/net/drivers/efi/efinet.c |  8 ++--
 include/grub/efi/efi.h |  3 +++
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/grub-core/kern/efi/efi.c b/grub-core/kern/efi/efi.c
index 8cff7be02..d4268d062 100644
--- a/grub-core/kern/efi/efi.c
+++ b/grub-core/kern/efi/efi.c
@@ -117,6 +117,18 @@ grub_efi_open_protocol (grub_efi_handle_t handle,
   return interface;
 }
 
+grub_efi_status_t
+grub_efi_close_protocol (grub_efi_handle_t handle, grub_efi_guid_t *protocol)
+{
+  grub_efi_boot_services_t *b = grub_efi_system_table->boot_services;
+  grub_efi_status_t status;
+
+  status = efi_call_4 (b->close_protocol, handle, protocol,
+  grub_efi_image_handle, NULL);
+
+  return status;
+}
+
 int
 grub_efi_set_text_mode (int on)
 {
diff --git a/grub-core/net/drivers/efi/efinet.c 
b/grub-core/net/drivers/efi/efinet.c
index bcd812ff5..186a8a03c 100644
--- a/grub-core/net/drivers/efi/efinet.c
+++ b/grub-core/net/drivers/efi/efinet.c
@@ -156,9 +156,7 @@ open_card (struct grub_net_card *dev)
 
   if (dev->efi_net != NULL)
 {
-  efi_call_4 (grub_efi_system_table->boot_services->close_protocol,
- dev->efi_handle, _io_guid,
- grub_efi_image_handle, NULL);
+  grub_efi_close_protocol (dev->efi_handle, _io_guid);
   dev->efi_net = NULL;
 }
   /*
@@ -220,9 +218,7 @@ close_card (struct grub_net_card *dev)
 {
   efi_call_1 (dev->efi_net->shutdown, dev->efi_net);
   efi_call_1 (dev->efi_net->stop, dev->efi_net);
-  efi_call_4 (grub_efi_system_table->boot_services->close_protocol,
- dev->efi_handle, _io_guid,
- grub_efi_image_handle, 0);
+  grub_efi_close_protocol (dev->efi_handle, _io_guid);
 }
 
 static struct grub_net_card_driver efidriver =
diff --git a/include/grub/efi/efi.h b/include/grub/efi/efi.h
index 83d958f99..12d041f2e 100644
--- a/include/grub/efi/efi.h
+++ b/include/grub/efi/efi.h
@@ -35,6 +35,9 @@ EXPORT_FUNC(grub_efi_locate_handle) 
(grub_efi_locate_search_type_t search_type,
 void *EXPORT_FUNC(grub_efi_open_protocol) (grub_efi_handle_t handle,
   grub_efi_guid_t *protocol,
   grub_efi_uint32_t attributes);
+grub_efi_status_t
+EXPORT_FUNC(grub_efi_close_protocol) (grub_efi_handle_t handle,
+ grub_efi_guid_t *protocol);
 int EXPORT_FUNC(grub_efi_set_text_mode) (int on);
 void EXPORT_FUNC(grub_efi_stall) (grub_efi_uintn_t microseconds);
 void *
-- 
2.32.0


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH v2 0/2] efinet: correct closing of SNP protocol

2021-11-29 Thread Heinrich Schuchardt

In the context of the implementation of the EFI_LOAD_FILE2_PROTOCOL for
the initial ramdisk it was observed that opening the SNP protocol failed
(https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00020.html).
This is due to an incorrect call to CloseProtocol().

This is corrected in the first patch.

The second patch provides a new function grub_efi_close_protocol() to
simplify the coding.

v2:
do not open SNP protocol non-exclusively
adjust code style

Heinrich Schuchardt (2):
  efinet: correct closing of SNP protocol
  efi: library function grub_efi_close_protocol()

 grub-core/kern/efi/efi.c   | 12 
 grub-core/net/drivers/efi/efinet.c | 29 +++--
 include/grub/efi/efi.h |  3 +++
 3 files changed, 34 insertions(+), 10 deletions(-)

-- 
2.32.0


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub2 + xen + lz4 kernels

Re: grub2 + xen + lz4 kernels

grub2 + xen + lz4 kernels

Re: [PATCH] Drop gnulib fix-base64.patch

Re: [PATCH v2 2/2] Make a "gdb" dprintf that tells us load addresses

[PATCH v2 1/2] efinet: correct closing of SNP protocol

[PATCH v2 2/2] efi: library function grub_efi_close_protocol()

[PATCH v2 0/2] efinet: correct closing of SNP protocol

8 matches

Site Navigation

Mail list logo

Footer information