[PATCH 7/9] btrfs: Add support for recovery for a RAID 5 btrfs profiles.
From: Goffredo Baroncelli
Add support for recovery for a RAID 5 btrfs profile. In addition
it is added some code as preparatory work for RAID 6 recovery code.
Signed-off-by: Goffredo Baroncelli
---
grub-core/fs/btrfs.c | 161 +--
1 file changed, 156 insertions(+), 5 deletions(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index ea97f0502..b277f2904 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
GRUB_MOD_LICENSE ("GPLv3+");
@@ -665,6 +666,140 @@ btrfs_read_from_chunk (struct grub_btrfs_data *data,
return err;
}
+struct raid56_buffer {
+ void *buf;
+ int data_is_valid;
+};
+
+static void
+rebuild_raid5 (char *dest, struct raid56_buffer *buffers,
+ grub_uint64_t nstripes, grub_uint64_t csize)
+{
+ grub_uint64_t i;
+ int first;
+
+ for(i = 0; buffers[i].data_is_valid && i < nstripes; i++);
+
+ if (i == nstripes)
+{
+ grub_dprintf ("btrfs", "called rebuild_raid5(), but all disks are OK\n");
+ return;
+}
+
+ grub_dprintf ("btrfs", "rebuilding RAID 5 stripe #%" PRIuGRUB_UINT64_T "\n",
i);
+
+ for (i = 0, first = 1; i < nstripes; i++)
+{
+ if (!buffers[i].data_is_valid)
+ continue;
+
+ if (first) {
+ grub_memcpy(dest, buffers[i].buf, csize);
+ first = 0;
+ } else
+ grub_crypto_xor (dest, dest, buffers[i].buf, csize);
+}
+}
+
+static grub_err_t
+raid56_read_retry (struct grub_btrfs_data *data,
+ struct grub_btrfs_chunk_item *chunk,
+ grub_uint64_t stripe_offset,
+ grub_uint64_t csize, void *buf)
+{
+ struct raid56_buffer *buffers;
+ grub_uint64_t nstripes = grub_le_to_cpu16 (chunk->nstripes);
+ grub_uint64_t chunk_type = grub_le_to_cpu64 (chunk->type);
+ grub_err_t ret = GRUB_ERR_OUT_OF_MEMORY;
+ grub_uint64_t i, failed_devices;
+
+ buffers = grub_zalloc (sizeof(*buffers) * nstripes);
+ if (!buffers)
+goto cleanup;
+
+ for (i = 0; i < nstripes; i++)
+{
+ buffers[i].buf = grub_zalloc (csize);
+ if (!buffers[i].buf)
+ goto cleanup;
+}
+
+ for (failed_devices = 0, i = 0; i < nstripes; i++)
+{
+ struct grub_btrfs_chunk_stripe *stripe;
+ grub_disk_addr_t paddr;
+ grub_device_t dev;
+ grub_err_t err;
+
+ /* The struct grub_btrfs_chunk_stripe array lives behind struct
+grub_btrfs_chunk_item. */
+ stripe = (struct grub_btrfs_chunk_stripe *) (chunk + 1) + i;
+
+ paddr = grub_le_to_cpu64 (stripe->offset) + stripe_offset;
+ grub_dprintf ("btrfs", "reading paddr %" PRIxGRUB_UINT64_T
+" from stripe ID %" PRIxGRUB_UINT64_T "\n", paddr,
+stripe->device_id);
+
+ dev = find_device (data, stripe->device_id);
+ if (!dev)
+ {
+ buffers[i].data_is_valid = 0;
+ grub_dprintf ("btrfs", "stripe %" PRIuGRUB_UINT64_T " FAILED (dev ID
%"
+ PRIxGRUB_UINT64_T ")\n", i, stripe->device_id);
+ failed_devices++;
+ continue;
+ }
+
+ err = grub_disk_read (dev->disk, paddr >> GRUB_DISK_SECTOR_BITS,
+ paddr & (GRUB_DISK_SECTOR_SIZE - 1),
+ csize, buffers[i].buf);
+ if (err == GRUB_ERR_NONE)
+ {
+ buffers[i].data_is_valid = 1;
+ grub_dprintf ("btrfs", "stripe %" PRIuGRUB_UINT64_T " OK (dev ID %"
+ PRIxGRUB_UINT64_T ")\n", i, stripe->device_id);
+ }
+ else
+ {
+ buffers[i].data_is_valid = 0;
+ grub_dprintf ("btrfs", "stripe %" PRIuGRUB_UINT64_T
+ " FAILED (dev ID %" PRIxGRUB_UINT64_T ")\n", i,
+ stripe->device_id);
+ failed_devices++;
+ }
+}
+
+ if (failed_devices > 1 && (chunk_type & GRUB_BTRFS_CHUNK_TYPE_RAID5))
+{
+ grub_dprintf ("btrfs",
+ "not enough disks for RAID 5: total %" PRIuGRUB_UINT64_T
+ ", missing %" PRIuGRUB_UINT64_T "\n",
+ nstripes, failed_devices);
+ ret = GRUB_ERR_READ_ERROR;
+ goto cleanup;
+}
+ else
+grub_dprintf ("btrfs",
+ "enough disks for RAID 5: total %"
+ PRIuGRUB_UINT64_T ", missing %" PRIuGRUB_UINT64_T "\n",
+ nstripes, failed_devices);
+
+ /* We have enough disks. So, rebuild the data. */
+ if (chunk_type & GRUB_BTRFS_CHUNK_TYPE_RAID5)
+rebuild_raid5 (buf, buffers, nstripes, csize);
+ else
+grub_dprintf ("btrfs", "called rebuild_raid6(), NOT IMPLEMENTED\n");
+
+ ret = GRUB_ERR_NONE;
+ cleanup:
+ if (buffers)
+for (i = 0; i < nstripes; i++)
+ grub_free (buffers[i].buf);
+ grub_free (buffers);
+
+ return ret;
+}
+
static grub_err_t
grub_btrfs_read_logical (struct grub_btrfs_data *data, grub_disk_addr_t addr,
void *buf, grub_size_t size, int recursion_depth)
@@
[PATCH 8/9] btrfs: Make more generic the code for RAID 6 rebuilding
From: Goffredo Baroncelli
The original code which handles the recovery of a RAID 6 disks array
assumes that all reads are multiple of 1 << GRUB_DISK_SECTOR_BITS and it
assumes that all the I/O is done via the struct grub_diskfilter_segment.
This is not true for the btrfs code. In order to reuse the native
grub_raid6_recover() code, it is modified to not call
grub_diskfilter_read_node() directly, but to call an handler passed
as an argument.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/disk/raid6_recover.c | 52 ++
include/grub/diskfilter.h | 9 ++
2 files changed, 43 insertions(+), 18 deletions(-)
diff --git a/grub-core/disk/raid6_recover.c b/grub-core/disk/raid6_recover.c
index aa674f6ca..0cf691ddf 100644
--- a/grub-core/disk/raid6_recover.c
+++ b/grub-core/disk/raid6_recover.c
@@ -74,14 +74,26 @@ mod_255 (unsigned x)
}
static grub_err_t
-grub_raid6_recover (struct grub_diskfilter_segment *array, int disknr, int p,
-char *buf, grub_disk_addr_t sector, grub_size_t size)
+raid6_recover_read_node (void *data, int disknr,
+ grub_uint64_t sector,
+ void *buf, grub_size_t size)
+{
+struct grub_diskfilter_segment *array = data;
+
+return grub_diskfilter_read_node (>nodes[disknr],
+ (grub_disk_addr_t)sector,
+ size >> GRUB_DISK_SECTOR_BITS, buf);
+}
+
+grub_err_t
+grub_raid6_recover_gen (void *data, grub_uint64_t nstripes, int disknr, int p,
+ char *buf, grub_uint64_t sector, grub_size_t size,
+ int layout, raid_recover_read_t read_func)
{
int i, q, pos;
int bad1 = -1, bad2 = -1;
char *pbuf = 0, *qbuf = 0;
- size <<= GRUB_DISK_SECTOR_BITS;
pbuf = grub_zalloc (size);
if (!pbuf)
goto quit;
@@ -91,17 +103,17 @@ grub_raid6_recover (struct grub_diskfilter_segment *array,
int disknr, int p,
goto quit;
q = p + 1;
- if (q == (int) array->node_count)
+ if (q == (int) nstripes)
q = 0;
pos = q + 1;
- if (pos == (int) array->node_count)
+ if (pos == (int) nstripes)
pos = 0;
- for (i = 0; i < (int) array->node_count - 2; i++)
+ for (i = 0; i < (int) nstripes - 2; i++)
{
int c;
- if (array->layout & GRUB_RAID_LAYOUT_MUL_FROM_POS)
+ if (layout & GRUB_RAID_LAYOUT_MUL_FROM_POS)
c = pos;
else
c = i;
@@ -109,8 +121,7 @@ grub_raid6_recover (struct grub_diskfilter_segment *array,
int disknr, int p,
bad1 = c;
else
{
- if (! grub_diskfilter_read_node (>nodes[pos], sector,
- size >> GRUB_DISK_SECTOR_BITS, buf))
+ if (!read_func(data, pos, sector, buf, size))
{
grub_crypto_xor (pbuf, pbuf, buf, size);
grub_raid_block_mulx (c, buf, size);
@@ -128,7 +139,7 @@ grub_raid6_recover (struct grub_diskfilter_segment *array,
int disknr, int p,
}
pos++;
- if (pos == (int) array->node_count)
+ if (pos == (int) nstripes)
pos = 0;
}
@@ -139,16 +150,14 @@ grub_raid6_recover (struct grub_diskfilter_segment
*array, int disknr, int p,
if (bad2 < 0)
{
/* One bad device */
- if ((! grub_diskfilter_read_node (>nodes[p], sector,
- size >> GRUB_DISK_SECTOR_BITS, buf)))
+ if (!read_func(data, p, sector, buf, size))
{
grub_crypto_xor (buf, buf, pbuf, size);
goto quit;
}
grub_errno = GRUB_ERR_NONE;
- if (grub_diskfilter_read_node (>nodes[q], sector,
-size >> GRUB_DISK_SECTOR_BITS, buf))
+ if (read_func(data, q, sector, buf, size))
goto quit;
grub_crypto_xor (buf, buf, qbuf, size);
@@ -160,14 +169,12 @@ grub_raid6_recover (struct grub_diskfilter_segment
*array, int disknr, int p,
/* Two bad devices */
unsigned c;
- if (grub_diskfilter_read_node (>nodes[p], sector,
-size >> GRUB_DISK_SECTOR_BITS, buf))
+ if (read_func(data, p, sector, buf, size))
goto quit;
grub_crypto_xor (pbuf, pbuf, buf, size);
- if (grub_diskfilter_read_node (>nodes[q], sector,
-size >> GRUB_DISK_SECTOR_BITS, buf))
+ if (read_func(data, q, sector, buf, size))
goto quit;
grub_crypto_xor (qbuf, qbuf, buf, size);
@@ -190,6 +197,15 @@ quit:
return grub_errno;
}
+static grub_err_t
+grub_raid6_recover (struct grub_diskfilter_segment *array, int disknr, int p,
+char *buf, grub_disk_addr_t sector, grub_size_t size)
+{
+ return grub_raid6_recover_gen (array, array->node_count, disknr, p, buf,
+sector, size << GRUB_DISK_SECTOR_BITS,
+
[PATCH 4/9] btrfs: Avoid a rescan for a device which was already not found.
From: Goffredo Baroncelli
Currently read from missing device triggers rescan. However, it is never
recorded that the device is missing. So, each read of a missing device
triggers rescan again and again. This behavior causes a lot of unneeded
rescans leading to huge slowdowns.
This patch fixes above mentioned issue. Information about missing devices
is stored in the data->devices_attached[] array as NULL value in dev
member. Rescan is triggered only if no information is found for a given
device. This means that only first time read triggers rescan.
The patch drops premature return. This way data->devices_attached[] is
filled even when a given device is missing.
Signed-off-by: Goffredo Baroncelli
Signed-off-by: Daniel Kiper
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index 6b6e91cd1..81f3bc120 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -588,7 +588,7 @@ find_device_iter (const char *name, void *data)
}
static grub_device_t
-find_device (struct grub_btrfs_data *data, grub_uint64_t id, int do_rescan)
+find_device (struct grub_btrfs_data *data, grub_uint64_t id)
{
struct find_device_ctx ctx = {
.data = data,
@@ -600,10 +600,9 @@ find_device (struct grub_btrfs_data *data, grub_uint64_t
id, int do_rescan)
for (i = 0; i < data->n_devices_attached; i++)
if (id == data->devices_attached[i].id)
return data->devices_attached[i].dev;
- if (do_rescan)
-grub_device_iterate (find_device_iter, );
- if (!ctx.dev_found)
-return NULL;
+
+ grub_device_iterate (find_device_iter, );
+
data->n_devices_attached++;
if (data->n_devices_attached > data->n_devices_allocated)
{
@@ -615,7 +614,8 @@ find_device (struct grub_btrfs_data *data, grub_uint64_t
id, int do_rescan)
* sizeof (data->devices_attached[0]));
if (!data->devices_attached)
{
- grub_device_close (ctx.dev_found);
+ if (ctx.dev_found)
+ grub_device_close (ctx.dev_found);
data->devices_attached = tmp;
return NULL;
}
@@ -897,7 +897,7 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
" for laddr 0x%" PRIxGRUB_UINT64_T "\n", paddr,
addr);
- dev = find_device (data, stripe->device_id, j);
+ dev = find_device (data, stripe->device_id);
if (!dev)
{
grub_dprintf ("btrfs",
@@ -974,7 +974,8 @@ grub_btrfs_unmount (struct grub_btrfs_data *data)
unsigned i;
/* The device 0 is closed one layer upper. */
for (i = 1; i < data->n_devices_attached; i++)
-grub_device_close (data->devices_attached[i].dev);
+if (data->devices_attached[i].dev)
+grub_device_close (data->devices_attached[i].dev);
grub_free (data->devices_attached);
grub_free (data->extent);
grub_free (data);
--
2.19.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH V10] Add support for BTRFS raid5/6 to GRUB
Hi All,
the aim of this patches set is to provide support for a BTRFS raid5/6
filesystem in GRUB.
The first patch, implements the basic support for raid5/6. I.e this works when
all the disks are present.
The next 5 patches, are preparatory ones.
The 7th patch implements the raid5 recovery for btrfs (i.e. handling the
disappearing of 1 disk).
The 8th patch makes the code for handling the raid6 recovery more generic.
The last one implements the raid6 recovery for btrfs (i.e. handling the
disappearing up to two disks).
I tested the code in grub-emu, and it works both with all the disks,
and with some disks missing. I checked the crc32 calculated from grub and
from linux and these matched. Finally I checked if the support for md raid6
still works properly, and it does (with all drives and with up to 2 drives
missing)
Comments are welcome.
Changelog
v1: initial support for btrfs raid5/6. No recovery allowed
v2: full support for btrfs raid5/6. Recovery allowed
v3: some minor cleanup suggested by Daniel Kiper; reusing the
original raid6 recovery code of grub
v4: Several spell fix; better description of the RAID layout
in btrfs, and the variables which describes the stripe
positioning; split the patch #5 in two (#5 and #6)
v5: Several spell fix; improved code comment in patch #1, small
clean up in the code
v6: Small cleanup; improved the wording in the RAID6 layout
description; in the function raid6_recover_read_buffer() avoid
a unnecessary memcpy in case of invalid data;
v7: - patch 2,3,5,6,8 received an Review-by Daniel, and were unchanged from
the last time (only minor cleanup in the commit description requested by
Daniel)
- patch 7 received some small update rearranging a for(), and some
bracket around if()
- patch 4, received an update message which explains better why NULL
is stored in data->devices_attached[]
- patch 9, received a blank line to separate better a code line from
a previous comment. A description of 'parities_pos' was added
- patch 1, received a major update about the variable meaning description
in the comment. However I suspect that we need some further review to reach
a fully agreement about this text. NB: the update are relate only to
comments
v8: - patch 2,5,6,8 received an Review-by Daniel, and were unchanged from
the last time (only minor cleanup in the commit description requested by
Daniel)
- patch 1 received some adjustement to the variables description due to
the different terminology between BTRFS and other RAID implementatio.
Added a description for the "nparities" variable.
- patch 3 removed some unnecessary curly brackets (change request by Daniel)
- patch 4 received an improved commit description about why and how
the function find_device() is changed
- patch 7 received an update which transforms a i = 0; while(i..) i++; in
for( i = 0. ; i++);
- patch 9 received an update to the comment
v9: - patch 1: update comments
- patch 4: update commit messages
- patch 7: added a comment about accessing an array of structs
after another structs; changed if(err == GRUB_ERR_NONE) in if(!err)
changed if(err != GRUB_ERR_NONE) in if(err)
v10:- patch 1: update comments (replace might with can)
- patch 4: add a Signed off by Daniel
- patch 7: drop an empty line; changed some text in grub_dprintf;
reversed the logic of an if (if(!is_raid56) A else B -> if(is_raid5) B
else A); add a space between the function name and the '('
- patch 9: update the wording in the comment; s/raid6/RAID 6/ in
grub_dprintf()
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 6/9] btrfs: Refactor the code that read from disk
From: Goffredo Baroncelli
Move the code in charge to read the data from disk into a separate
function. This helps to separate the error handling logic (which depends on
the different raid profiles) from the read from disk logic.
Refactoring this code increases the general readability too.
This is a preparatory patch, to help the adding of the RAID 5/6 recovery
code.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 75 ++--
1 file changed, 44 insertions(+), 31 deletions(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index dde0edd03..ea97f0502 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -625,6 +625,46 @@ find_device (struct grub_btrfs_data *data, grub_uint64_t
id)
return ctx.dev_found;
}
+static grub_err_t
+btrfs_read_from_chunk (struct grub_btrfs_data *data,
+ struct grub_btrfs_chunk_item *chunk,
+ grub_uint64_t stripen, grub_uint64_t stripe_offset,
+ int redundancy, grub_uint64_t csize,
+ void *buf)
+{
+struct grub_btrfs_chunk_stripe *stripe;
+grub_disk_addr_t paddr;
+grub_device_t dev;
+grub_err_t err;
+
+stripe = (struct grub_btrfs_chunk_stripe *) (chunk + 1);
+/* Right now the redundancy handling is easy.
+ With RAID5-like it will be more difficult. */
+stripe += stripen + redundancy;
+
+paddr = grub_le_to_cpu64 (stripe->offset) + stripe_offset;
+
+grub_dprintf ("btrfs", "stripe %" PRIxGRUB_UINT64_T
+ " maps to 0x%" PRIxGRUB_UINT64_T
+ ". Reading paddr 0x%" PRIxGRUB_UINT64_T "\n",
+ stripen, stripe->offset, paddr);
+
+dev = find_device (data, stripe->device_id);
+if (!dev)
+ {
+ grub_dprintf ("btrfs",
+ "couldn't find a necessary member device "
+ "of multi-device filesystem\n");
+ grub_errno = GRUB_ERR_NONE;
+ return GRUB_ERR_READ_ERROR;
+ }
+
+err = grub_disk_read (dev->disk, paddr >> GRUB_DISK_SECTOR_BITS,
+ paddr & (GRUB_DISK_SECTOR_SIZE - 1),
+ csize, buf);
+return err;
+}
+
static grub_err_t
grub_btrfs_read_logical (struct grub_btrfs_data *data, grub_disk_addr_t addr,
void *buf, grub_size_t size, int recursion_depth)
@@ -638,7 +678,6 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
grub_err_t err = 0;
struct grub_btrfs_key key_out;
int challoc = 0;
- grub_device_t dev;
struct grub_btrfs_key key_in;
grub_size_t chsize;
grub_disk_addr_t chaddr;
@@ -884,36 +923,10 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
for (i = 0; i < redundancy; i++)
{
- struct grub_btrfs_chunk_stripe *stripe;
- grub_disk_addr_t paddr;
-
- stripe = (struct grub_btrfs_chunk_stripe *) (chunk + 1);
- /* Right now the redundancy handling is easy.
- With RAID5-like it will be more difficult. */
- stripe += stripen + i;
-
- paddr = grub_le_to_cpu64 (stripe->offset) + stripe_offset;
-
- grub_dprintf ("btrfs", "stripe %" PRIxGRUB_UINT64_T
- " maps to 0x%" PRIxGRUB_UINT64_T "\n",
- stripen, stripe->offset);
- grub_dprintf ("btrfs", "reading paddr 0x%" PRIxGRUB_UINT64_T
- "\n", paddr);
-
- dev = find_device (data, stripe->device_id);
- if (!dev)
- {
- grub_dprintf ("btrfs",
- "couldn't find a necessary member device "
- "of multi-device filesystem\n");
- err = grub_errno;
- grub_errno = GRUB_ERR_NONE;
- continue;
- }
-
- err = grub_disk_read (dev->disk, paddr >> GRUB_DISK_SECTOR_BITS,
- paddr & (GRUB_DISK_SECTOR_SIZE - 1),
- csize, buf);
+ err = btrfs_read_from_chunk (data, chunk, stripen,
+stripe_offset,
+i, /* redundancy */
+csize, buf);
if (!err)
break;
grub_errno = GRUB_ERR_NONE;
--
2.19.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 06/18] xen: rearrange xen/init.c to prepare it for Xen PVH mode
On Tue, Oct 09, 2018 at 01:03:05PM +0200, Juergen Gross wrote: > Rearrange grub-core/kern/xen/init.c to prepare adding PVH mode support > to it. This includes putting some code under #ifdef GRUB_MACHINE_XEN > as it will not be used when running as PVH. > > Signed-off-by: Juergen Gross Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 2/9] btrfs: Add helper to check the btrfs header.
From: Goffredo Baroncelli
This helper is used in a few places to help the debugging. As
conservative approach the error is only logged.
This does not impact the error handling.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index 9122169aa..0cbf3551a 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -77,7 +77,8 @@ struct btrfs_header
{
grub_btrfs_checksum_t checksum;
grub_btrfs_uuid_t uuid;
- grub_uint8_t dummy[0x30];
+ grub_uint64_t bytenr;
+ grub_uint8_t dummy[0x28];
grub_uint32_t nitems;
grub_uint8_t level;
} GRUB_PACKED;
@@ -286,6 +287,25 @@ free_iterator (struct grub_btrfs_leaf_descriptor *desc)
grub_free (desc->data);
}
+static grub_err_t
+check_btrfs_header (struct grub_btrfs_data *data, struct btrfs_header *header,
+grub_disk_addr_t addr)
+{
+ if (grub_le_to_cpu64 (header->bytenr) != addr)
+{
+ grub_dprintf ("btrfs", "btrfs_header.bytenr is not equal node addr\n");
+ return grub_error (GRUB_ERR_BAD_FS,
+"header bytenr is not equal node addr");
+}
+ if (grub_memcmp (data->sblock.uuid, header->uuid, sizeof(grub_btrfs_uuid_t)))
+{
+ grub_dprintf ("btrfs", "btrfs_header.uuid doesn't match sblock uuid\n");
+ return grub_error (GRUB_ERR_BAD_FS,
+"header uuid doesn't match sblock uuid");
+}
+ return GRUB_ERR_NONE;
+}
+
static grub_err_t
save_ref (struct grub_btrfs_leaf_descriptor *desc,
grub_disk_addr_t addr, unsigned i, unsigned m, int l)
@@ -341,6 +361,7 @@ next (struct grub_btrfs_data *data,
err = grub_btrfs_read_logical (data, grub_le_to_cpu64 (node.addr),
, sizeof (head), 0);
+ check_btrfs_header (data, , grub_le_to_cpu64 (node.addr));
if (err)
return -err;
@@ -402,6 +423,7 @@ lower_bound (struct grub_btrfs_data *data,
/* FIXME: preread few nodes into buffer. */
err = grub_btrfs_read_logical (data, addr, , sizeof (head),
recursion_depth + 1);
+ check_btrfs_header (data, , addr);
if (err)
return err;
addr += sizeof (head);
--
2.19.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 5/9] btrfs: Move logging code in grub_btrfs_read_logical()
From: Goffredo Baroncelli
A portion of the logging code is moved outside of internal for(;;). The part
that is left inside is the one which depends on the internal for(;;) index.
This is a preparatory patch. The next one will refactor the code inside
the for(;;) into an another function.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index 81f3bc120..dde0edd03 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -870,6 +870,18 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
for (j = 0; j < 2; j++)
{
+ grub_dprintf ("btrfs", "chunk 0x%" PRIxGRUB_UINT64_T
+ "+0x%" PRIxGRUB_UINT64_T
+ " (%d stripes (%d substripes) of %"
+ PRIxGRUB_UINT64_T ")\n",
+ grub_le_to_cpu64 (key->offset),
+ grub_le_to_cpu64 (chunk->size),
+ grub_le_to_cpu16 (chunk->nstripes),
+ grub_le_to_cpu16 (chunk->nsubstripes),
+ grub_le_to_cpu64 (chunk->stripe_length));
+ grub_dprintf ("btrfs", "reading laddr 0x%" PRIxGRUB_UINT64_T "\n",
+ addr);
+
for (i = 0; i < redundancy; i++)
{
struct grub_btrfs_chunk_stripe *stripe;
@@ -882,20 +894,11 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
paddr = grub_le_to_cpu64 (stripe->offset) + stripe_offset;
- grub_dprintf ("btrfs", "chunk 0x%" PRIxGRUB_UINT64_T
- "+0x%" PRIxGRUB_UINT64_T
- " (%d stripes (%d substripes) of %"
- PRIxGRUB_UINT64_T ") stripe %" PRIxGRUB_UINT64_T
+ grub_dprintf ("btrfs", "stripe %" PRIxGRUB_UINT64_T
" maps to 0x%" PRIxGRUB_UINT64_T "\n",
- grub_le_to_cpu64 (key->offset),
- grub_le_to_cpu64 (chunk->size),
- grub_le_to_cpu16 (chunk->nstripes),
- grub_le_to_cpu16 (chunk->nsubstripes),
- grub_le_to_cpu64 (chunk->stripe_length),
stripen, stripe->offset);
grub_dprintf ("btrfs", "reading paddr 0x%" PRIxGRUB_UINT64_T
- " for laddr 0x%" PRIxGRUB_UINT64_T "\n", paddr,
- addr);
+ "\n", paddr);
dev = find_device (data, stripe->device_id);
if (!dev)
--
2.19.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 9/9] btrfs: Add RAID 6 recovery for a btrfs filesystem.
From: Goffredo Baroncelli
Add the RAID 6 recovery, in order to use a RAID 6 filesystem even if some
disks (up to two) are missing. This code use the md RAID 6 code already
present in grub.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 60 +++-
1 file changed, 54 insertions(+), 6 deletions(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index b277f2904..9419d313d 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
GRUB_MOD_LICENSE ("GPLv3+");
@@ -701,11 +702,36 @@ rebuild_raid5 (char *dest, struct raid56_buffer *buffers,
}
}
+static grub_err_t
+raid6_recover_read_buffer (void *data, int disk_nr,
+ grub_uint64_t addr __attribute__ ((unused)),
+ void *dest, grub_size_t size)
+{
+struct raid56_buffer *buffers = data;
+
+if (!buffers[disk_nr].data_is_valid)
+ return grub_errno = GRUB_ERR_READ_ERROR;
+
+grub_memcpy(dest, buffers[disk_nr].buf, size);
+
+return grub_errno = GRUB_ERR_NONE;
+}
+
+static void
+rebuild_raid6 (struct raid56_buffer *buffers, grub_uint64_t nstripes,
+ grub_uint64_t csize, grub_uint64_t parities_pos, void *dest,
+ grub_uint64_t stripen)
+
+{
+ grub_raid6_recover_gen (buffers, nstripes, stripen, parities_pos,
+ dest, 0, csize, 0, raid6_recover_read_buffer);
+}
+
static grub_err_t
raid56_read_retry (struct grub_btrfs_data *data,
struct grub_btrfs_chunk_item *chunk,
- grub_uint64_t stripe_offset,
- grub_uint64_t csize, void *buf)
+ grub_uint64_t stripe_offset, grub_uint64_t stripen,
+ grub_uint64_t csize, void *buf, grub_uint64_t parities_pos)
{
struct raid56_buffer *buffers;
grub_uint64_t nstripes = grub_le_to_cpu16 (chunk->nstripes);
@@ -778,6 +804,15 @@ raid56_read_retry (struct grub_btrfs_data *data,
ret = GRUB_ERR_READ_ERROR;
goto cleanup;
}
+ else if (failed_devices > 2 && (chunk_type & GRUB_BTRFS_CHUNK_TYPE_RAID6))
+{
+ grub_dprintf ("btrfs",
+ "not enough disks for RAID 6: total %" PRIuGRUB_UINT64_T
+ ", missing %" PRIuGRUB_UINT64_T "\n",
+ nstripes, failed_devices);
+ ret = GRUB_ERR_READ_ERROR;
+ goto cleanup;
+}
else
grub_dprintf ("btrfs",
"enough disks for RAID 5: total %"
@@ -788,7 +823,7 @@ raid56_read_retry (struct grub_btrfs_data *data,
if (chunk_type & GRUB_BTRFS_CHUNK_TYPE_RAID5)
rebuild_raid5 (buf, buffers, nstripes, csize);
else
-grub_dprintf ("btrfs", "called rebuild_raid6(), NOT IMPLEMENTED\n");
+rebuild_raid6 (buffers, nstripes, csize, parities_pos, buf, stripen);
ret = GRUB_ERR_NONE;
cleanup:
@@ -878,9 +913,11 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
unsigned redundancy = 1;
unsigned i, j;
int is_raid56;
+ grub_uint64_t parities_pos = 0;
- is_raid56 = !!(grub_le_to_cpu64 (chunk->type) &
- GRUB_BTRFS_CHUNK_TYPE_RAID5);
+is_raid56 = !!(grub_le_to_cpu64 (chunk->type) &
+ (GRUB_BTRFS_CHUNK_TYPE_RAID5 |
+ GRUB_BTRFS_CHUNK_TYPE_RAID6));
if (grub_le_to_cpu64 (chunk->size) <= off)
{
@@ -1029,6 +1066,17 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
*/
grub_divmod64 (high + stripen, nstripes, );
+ /*
+ * parities_pos is equal to "(high - nparities) % nstripes"
+ * (see the diagram above).
+ * However "high - nparities" can be negative, eg. when high
+ * == 0 leading to an incorrect computation.
+ * "high + nstripes - nparities" is always positive and in
+ * modulo nstripes is equal to "(high - nparities) % nstripes"
+ */
+ grub_divmod64 (high + nstripes - nparities, nstripes,
+_pos);
+
stripe_offset = low + chunk_stripe_length * high;
csize = chunk_stripe_length - low;
@@ -1069,7 +1117,7 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
grub_errno = GRUB_ERR_NONE;
if (err)
err = raid56_read_retry (data, chunk, stripe_offset,
- csize, buf);
+ stripen, csize, buf, parities_pos);
}
else
for (i = 0; i < redundancy; i++)
--
2.19.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 1/9] btrfs: Add support for reading a filesystem with a RAID 5 or RAID 6 profile.
From: Goffredo Baroncelli
Signed-off-by: Goffredo Baroncelli
Signed-off-by: Daniel Kiper
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 73
1 file changed, 73 insertions(+)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index be195448d..9122169aa 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -119,6 +119,8 @@ struct grub_btrfs_chunk_item
#define GRUB_BTRFS_CHUNK_TYPE_RAID1 0x10
#define GRUB_BTRFS_CHUNK_TYPE_DUPLICATED0x20
#define GRUB_BTRFS_CHUNK_TYPE_RAID100x40
+#define GRUB_BTRFS_CHUNK_TYPE_RAID5 0x80
+#define GRUB_BTRFS_CHUNK_TYPE_RAID6 0x100
grub_uint8_t dummy2[0xc];
grub_uint16_t nstripes;
grub_uint16_t nsubstripes;
@@ -764,6 +766,77 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
stripe_offset = low + chunk_stripe_length
* high;
csize = chunk_stripe_length - low;
+ break;
+ }
+ case GRUB_BTRFS_CHUNK_TYPE_RAID5:
+ case GRUB_BTRFS_CHUNK_TYPE_RAID6:
+ {
+ grub_uint64_t nparities, stripe_nr, high, low;
+
+ redundancy = 1; /* no redundancy for now */
+
+ if (grub_le_to_cpu64 (chunk->type) & GRUB_BTRFS_CHUNK_TYPE_RAID5)
+ {
+ grub_dprintf ("btrfs", "RAID5\n");
+ nparities = 1;
+ }
+ else
+ {
+ grub_dprintf ("btrfs", "RAID6\n");
+ nparities = 2;
+ }
+
+ /*
+ * RAID 6 layout consists of several stripes spread over
+ * the disks, e.g.:
+ *
+ * Disk_0 Disk_1 Disk_2 Disk_3
+ * A0 B0 P0 Q0
+ * Q1 A1 B1 P1
+ * P2 Q2 A2 B2
+ *
+ * Note: placement of the parities depend on row number.
+ *
+ * Pay attention that the btrfs terminology may differ from
+ * terminology used in other RAID implementations, e.g. LVM,
+ * dm or md. The main difference is that btrfs calls contiguous
+ * block of data on a given disk, e.g. A0, stripe instead of
chunk.
+ *
+ * The variables listed below have following meaning:
+ * - stripe_nr is the stripe number excluding the parities
+ * (A0 = 0, B0 = 1, A1 = 2, B1 = 3, etc.),
+ * - high is the row number (0 for A0...Q0, 1 for Q1...P1,
etc.),
+ * - stripen is the disk number in a row (0 for A0, Q1, P2,
+ * 1 for B0, A1, Q2, etc.),
+ * - off is the logical address to read,
+ * - chunk_stripe_length is the size of a stripe (typically 64
KiB),
+ * - nstripes is the number of disks in a row,
+ * - low is the offset of the data inside a stripe,
+ * - stripe_offset is the data offset in an array,
+ * - csize is the "potential" data to read; it will be reduced
+ * to size if the latter is smaller,
+ * - nparities is the number of parities (1 for RAID 5, 2 for
+ * RAID 6); used only in RAID 5/6 code.
+ */
+ stripe_nr = grub_divmod64 (off, chunk_stripe_length, );
+
+ /*
+ * stripen is computed without the parities
+ * (0 for A0, A1, A2, 1 for B0, B1, B2, etc.).
+ */
+ high = grub_divmod64 (stripe_nr, nstripes - nparities, );
+
+ /*
+ * The stripes are spread over the disks. Every each row their
+ * positions are shifted by 1 place. So, the real disks number
+ * change. Hence, we have to take into account current row number
+ * modulo nstripes (0 for A0, 1 for A1, 2 for A2, etc.).
+ */
+ grub_divmod64 (high + stripen, nstripes, );
+
+ stripe_offset = low + chunk_stripe_length * high;
+ csize = chunk_stripe_length - low;
+
break;
}
default:
--
2.19.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 3/9] btrfs: Move the error logging from find_device() to its caller.
From: Goffredo Baroncelli
The caller knows better if this error is fatal or not, i.e. another disk is
available or not.
This is a preparatory patch.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index 0cbf3551a..6b6e91cd1 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -603,12 +603,7 @@ find_device (struct grub_btrfs_data *data, grub_uint64_t
id, int do_rescan)
if (do_rescan)
grub_device_iterate (find_device_iter, );
if (!ctx.dev_found)
-{
- grub_error (GRUB_ERR_BAD_FS,
- N_("couldn't find a necessary member device "
-"of multi-device filesystem"));
- return NULL;
-}
+return NULL;
data->n_devices_attached++;
if (data->n_devices_attached > data->n_devices_allocated)
{
@@ -905,6 +900,9 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
dev = find_device (data, stripe->device_id, j);
if (!dev)
{
+ grub_dprintf ("btrfs",
+ "couldn't find a necessary member device "
+ "of multi-device filesystem\n");
err = grub_errno;
grub_errno = GRUB_ERR_NONE;
continue;
--
2.19.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 05/18] xen: add some dummy headers for PVH mode
On 18/10/2018 17:19, Daniel Kiper wrote: > On Tue, Oct 09, 2018 at 01:03:04PM +0200, Juergen Gross wrote: >> Xen PVH mode needs some headers including the common i386 headers. >> Add those to the tree. >> >> Signed-off-by: Juergen Gross >> --- >> include/grub/i386/xenpvh/boot.h| 1 + >> include/grub/i386/xenpvh/console.h | 1 + >> include/grub/i386/xenpvh/int.h | 1 + >> include/grub/i386/xenpvh/memory.h | 1 + >> include/grub/i386/xenpvh/time.h| 1 + >> 5 files changed, 5 insertions(+) >> create mode 100644 include/grub/i386/xenpvh/boot.h >> create mode 100644 include/grub/i386/xenpvh/console.h >> create mode 100644 include/grub/i386/xenpvh/int.h >> create mode 100644 include/grub/i386/xenpvh/memory.h >> create mode 100644 include/grub/i386/xenpvh/time.h >> >> diff --git a/include/grub/i386/xenpvh/boot.h >> b/include/grub/i386/xenpvh/boot.h >> new file mode 100644 >> index 0..6cd23aa83 >> --- /dev/null >> +++ b/include/grub/i386/xenpvh/boot.h >> @@ -0,0 +1 @@ >> +#include >> diff --git a/include/grub/i386/xenpvh/console.h >> b/include/grub/i386/xenpvh/console.h >> new file mode 100644 >> index 0..305a46d8e >> --- /dev/null >> +++ b/include/grub/i386/xenpvh/console.h >> @@ -0,0 +1 @@ >> +#include >> diff --git a/include/grub/i386/xenpvh/int.h b/include/grub/i386/xenpvh/int.h >> new file mode 100644 >> index 0..6f9d14a81 >> --- /dev/null >> +++ b/include/grub/i386/xenpvh/int.h >> @@ -0,0 +1 @@ >> +#include >> diff --git a/include/grub/i386/xenpvh/memory.h >> b/include/grub/i386/xenpvh/memory.h >> new file mode 100644 >> index 0..8dd6f7c8c >> --- /dev/null >> +++ b/include/grub/i386/xenpvh/memory.h >> @@ -0,0 +1 @@ >> +#include >> diff --git a/include/grub/i386/xenpvh/time.h >> b/include/grub/i386/xenpvh/time.h >> new file mode 100644 >> index 0..2298ee8f4 >> --- /dev/null >> +++ b/include/grub/i386/xenpvh/time.h >> @@ -0,0 +1 @@ >> +#include > > I do not understand why we need these files. And commit message just states > just that we need them. However, it says nothing why... So, why? Who will > use them? Any source including grub/machine/*.h I'll make the commit message more verbose in this regard. Juergen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 04/18] xen: prepare common code for Xen PVH support
On 18/10/2018 16:59, Daniel Kiper wrote: > On Tue, Oct 09, 2018 at 01:03:03PM +0200, Juergen Gross wrote: >> Some common code needs to be special cased for Xen PVH mode. This hits >> mostly Xen PV mode specific areas. >> >> Signed-off-by: Juergen Gross >> --- >> grub-core/kern/i386/tsc.c | 2 +- >> include/grub/i386/pc/int.h| 3 +++ >> include/grub/i386/tsc.h | 2 +- >> include/grub/i386/xen/hypercall.h | 5 - >> include/grub/kernel.h | 4 +++- >> 5 files changed, 12 insertions(+), 4 deletions(-) >> >> diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c >> index f266eb131..43fee3a13 100644 >> --- a/grub-core/kern/i386/tsc.c >> +++ b/grub-core/kern/i386/tsc.c >> @@ -65,7 +65,7 @@ grub_tsc_init (void) >> >>tsc_boot_time = grub_get_tsc (); >> >> -#ifdef GRUB_MACHINE_XEN >> +#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH) > > s/GRUB_MACHINE_XENPVH/GRUB_MACHINE_XEN_PVH/ Okay. > >>(void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode()); >> #elif defined (GRUB_MACHINE_EFI) >>(void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit >> () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode()); >> diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h >> index 16a53e4fe..46fb1e397 100644 >> --- a/include/grub/i386/pc/int.h >> +++ b/include/grub/i386/pc/int.h >> @@ -51,9 +51,12 @@ struct grub_bios_int_registers >> #define GRUB_CPU_INT_FLAGS_DEFAULT 0 >> #endif >> >> +#ifndef GRUB_MACHINE_XENPVH >> void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno, >> struct grub_bios_int_registers *regs) >> __attribute__ ((regparm(3))); >> +#endif > > Is it an issue with this declaration? I think that you should take care > about grub-core/kern/i386/int.S. So, relevant Makefile should be > updated instead of this declaration. I'll have a try. I just remember I struggled a lot with this issue when writing the patches. Juergen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 05/18] xen: add some dummy headers for PVH mode
On Tue, Oct 09, 2018 at 01:03:04PM +0200, Juergen Gross wrote: > Xen PVH mode needs some headers including the common i386 headers. > Add those to the tree. > > Signed-off-by: Juergen Gross > --- > include/grub/i386/xenpvh/boot.h| 1 + > include/grub/i386/xenpvh/console.h | 1 + > include/grub/i386/xenpvh/int.h | 1 + > include/grub/i386/xenpvh/memory.h | 1 + > include/grub/i386/xenpvh/time.h| 1 + > 5 files changed, 5 insertions(+) > create mode 100644 include/grub/i386/xenpvh/boot.h > create mode 100644 include/grub/i386/xenpvh/console.h > create mode 100644 include/grub/i386/xenpvh/int.h > create mode 100644 include/grub/i386/xenpvh/memory.h > create mode 100644 include/grub/i386/xenpvh/time.h > > diff --git a/include/grub/i386/xenpvh/boot.h b/include/grub/i386/xenpvh/boot.h > new file mode 100644 > index 0..6cd23aa83 > --- /dev/null > +++ b/include/grub/i386/xenpvh/boot.h > @@ -0,0 +1 @@ > +#include > diff --git a/include/grub/i386/xenpvh/console.h > b/include/grub/i386/xenpvh/console.h > new file mode 100644 > index 0..305a46d8e > --- /dev/null > +++ b/include/grub/i386/xenpvh/console.h > @@ -0,0 +1 @@ > +#include > diff --git a/include/grub/i386/xenpvh/int.h b/include/grub/i386/xenpvh/int.h > new file mode 100644 > index 0..6f9d14a81 > --- /dev/null > +++ b/include/grub/i386/xenpvh/int.h > @@ -0,0 +1 @@ > +#include > diff --git a/include/grub/i386/xenpvh/memory.h > b/include/grub/i386/xenpvh/memory.h > new file mode 100644 > index 0..8dd6f7c8c > --- /dev/null > +++ b/include/grub/i386/xenpvh/memory.h > @@ -0,0 +1 @@ > +#include > diff --git a/include/grub/i386/xenpvh/time.h b/include/grub/i386/xenpvh/time.h > new file mode 100644 > index 0..2298ee8f4 > --- /dev/null > +++ b/include/grub/i386/xenpvh/time.h > @@ -0,0 +1 @@ > +#include I do not understand why we need these files. And commit message just states just that we need them. However, it says nothing why... So, why? Who will use them? Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
On Thu, Oct 18, 2018 at 04:53:01PM +0200, Juergen Gross wrote: > On 18/10/2018 16:48, Daniel Kiper wrote: > > On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote: > >> On 18/10/2018 16:30, Daniel Kiper wrote: > >>> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote: > On 18/10/2018 16:13, Daniel Kiper wrote: > > On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote: > >> Xen PVH guests will have the RSDP at an arbitrary address. Support that > >> by passing the RSDP address via the boot parameters to Linux. > >> > >> The new protocol version 2.14 requires to set version to 0x8000 ored > >> with the actually use protocol version (the minimum of the kernel > >> supplied protocol version and the grub2 supported protocol version) > >> if 2.14 or higher are in effect. > >> > >> Signed-off-by: Juergen Gross > >> --- > >> V2: add oring 0x8000 to version field > >> --- > >> grub-core/loader/i386/linux.c | 9 + > >> include/grub/i386/linux.h | 5 - > >> 2 files changed, 13 insertions(+), 1 deletion(-) > >> > >> diff --git a/grub-core/loader/i386/linux.c > >> b/grub-core/loader/i386/linux.c > >> index 4eab55a2d..f96309476 100644 > >> --- a/grub-core/loader/i386/linux.c > >> +++ b/grub-core/loader/i386/linux.c > >> @@ -35,6 +35,7 @@ > >> #include > >> #include > >> #include > >> +#include > > > > Probably this change belongs to another patch. > > I don't think so. > >>> > >>> You do not add anything to this header here and out of the blue you > >>> include it in this file. So, why it is needed here? > >> > >> Ah, now I see your problem. > >> > >> machine/kernel.h will be the header which eventually defines > >> GRUB_KERNEL_USE_RSDP_ADDR. > > > > So, please move this to the proper patch. > > Okay, if you like that better. Yes, I will. Thanks! Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 04/18] xen: prepare common code for Xen PVH support
On Tue, Oct 09, 2018 at 01:03:03PM +0200, Juergen Gross wrote: > Some common code needs to be special cased for Xen PVH mode. This hits > mostly Xen PV mode specific areas. > > Signed-off-by: Juergen Gross > --- > grub-core/kern/i386/tsc.c | 2 +- > include/grub/i386/pc/int.h| 3 +++ > include/grub/i386/tsc.h | 2 +- > include/grub/i386/xen/hypercall.h | 5 - > include/grub/kernel.h | 4 +++- > 5 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c > index f266eb131..43fee3a13 100644 > --- a/grub-core/kern/i386/tsc.c > +++ b/grub-core/kern/i386/tsc.c > @@ -65,7 +65,7 @@ grub_tsc_init (void) > >tsc_boot_time = grub_get_tsc (); > > -#ifdef GRUB_MACHINE_XEN > +#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH) s/GRUB_MACHINE_XENPVH/GRUB_MACHINE_XEN_PVH/ >(void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode()); > #elif defined (GRUB_MACHINE_EFI) >(void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit > () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode()); > diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h > index 16a53e4fe..46fb1e397 100644 > --- a/include/grub/i386/pc/int.h > +++ b/include/grub/i386/pc/int.h > @@ -51,9 +51,12 @@ struct grub_bios_int_registers > #define GRUB_CPU_INT_FLAGS_DEFAULT 0 > #endif > > +#ifndef GRUB_MACHINE_XENPVH > void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno, > struct grub_bios_int_registers *regs) > __attribute__ ((regparm(3))); > +#endif Is it an issue with this declaration? I think that you should take care about grub-core/kern/i386/int.S. So, relevant Makefile should be updated instead of this declaration. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote: > On 18/10/2018 16:30, Daniel Kiper wrote: > > On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote: > >> On 18/10/2018 16:13, Daniel Kiper wrote: > >>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote: > Xen PVH guests will have the RSDP at an arbitrary address. Support that > by passing the RSDP address via the boot parameters to Linux. > > The new protocol version 2.14 requires to set version to 0x8000 ored > with the actually use protocol version (the minimum of the kernel > supplied protocol version and the grub2 supported protocol version) > if 2.14 or higher are in effect. > > Signed-off-by: Juergen Gross > --- > V2: add oring 0x8000 to version field > --- > grub-core/loader/i386/linux.c | 9 + > include/grub/i386/linux.h | 5 - > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/grub-core/loader/i386/linux.c > b/grub-core/loader/i386/linux.c > index 4eab55a2d..f96309476 100644 > --- a/grub-core/loader/i386/linux.c > +++ b/grub-core/loader/i386/linux.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > >>> > >>> Probably this change belongs to another patch. > >> > >> I don't think so. > > > > You do not add anything to this header here and out of the blue you > > include it in this file. So, why it is needed here? > > Ah, now I see your problem. > > machine/kernel.h will be the header which eventually defines > GRUB_KERNEL_USE_RSDP_ADDR. So, please move this to the proper patch. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
On 18/10/2018 16:48, Daniel Kiper wrote: > On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote: >> On 18/10/2018 16:30, Daniel Kiper wrote: >>> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote: On 18/10/2018 16:13, Daniel Kiper wrote: > On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote: >> Xen PVH guests will have the RSDP at an arbitrary address. Support that >> by passing the RSDP address via the boot parameters to Linux. >> >> The new protocol version 2.14 requires to set version to 0x8000 ored >> with the actually use protocol version (the minimum of the kernel >> supplied protocol version and the grub2 supported protocol version) >> if 2.14 or higher are in effect. >> >> Signed-off-by: Juergen Gross >> --- >> V2: add oring 0x8000 to version field >> --- >> grub-core/loader/i386/linux.c | 9 + >> include/grub/i386/linux.h | 5 - >> 2 files changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/grub-core/loader/i386/linux.c >> b/grub-core/loader/i386/linux.c >> index 4eab55a2d..f96309476 100644 >> --- a/grub-core/loader/i386/linux.c >> +++ b/grub-core/loader/i386/linux.c >> @@ -35,6 +35,7 @@ >> #include >> #include >> #include >> +#include > > Probably this change belongs to another patch. I don't think so. >>> >>> You do not add anything to this header here and out of the blue you >>> include it in this file. So, why it is needed here? >> >> Ah, now I see your problem. >> >> machine/kernel.h will be the header which eventually defines >> GRUB_KERNEL_USE_RSDP_ADDR. > > So, please move this to the proper patch. Okay, if you like that better. Juergen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
On 18/10/2018 16:30, Daniel Kiper wrote:
> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
>> On 18/10/2018 16:13, Daniel Kiper wrote:
>>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
Xen PVH guests will have the RSDP at an arbitrary address. Support that
by passing the RSDP address via the boot parameters to Linux.
The new protocol version 2.14 requires to set version to 0x8000 ored
with the actually use protocol version (the minimum of the kernel
supplied protocol version and the grub2 supported protocol version)
if 2.14 or higher are in effect.
Signed-off-by: Juergen Gross
---
V2: add oring 0x8000 to version field
---
grub-core/loader/i386/linux.c | 9 +
include/grub/i386/linux.h | 5 -
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
index 4eab55a2d..f96309476 100644
--- a/grub-core/loader/i386/linux.c
+++ b/grub-core/loader/i386/linux.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
>>>
>>> Probably this change belongs to another patch.
>>
>> I don't think so.
>
> You do not add anything to this header here and out of the blue you
> include it in this file. So, why it is needed here?
Ah, now I see your problem.
machine/kernel.h will be the header which eventually defines
GRUB_KERNEL_USE_RSDP_ADDR.
>
GRUB_MOD_LICENSE ("GPLv3+");
@@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__
((unused)),
prot_init_space = page_align (prot_size) * 3;
}
+#ifdef GRUB_KERNEL_USE_RSDP_ADDR
+ if (grub_le_to_cpu16 (lh.version) >= 0x020e)
+lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
+#endif
>>>
>>> It seems to me that this belongs to patch #8. Does not it?
>>
>> No, it is a generic new interface.
>>
>> It will be used by PVH first, but can be used in other environments,
>> too.
>
> I do not like this much but if you want me to get it you have to put
> a blurb in the commit message why this is not enabled here. And when
> it will be enabled...
Okay, will do.
Juergen
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
> On 18/10/2018 16:13, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> >> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> >> by passing the RSDP address via the boot parameters to Linux.
> >>
> >> The new protocol version 2.14 requires to set version to 0x8000 ored
> >> with the actually use protocol version (the minimum of the kernel
> >> supplied protocol version and the grub2 supported protocol version)
> >> if 2.14 or higher are in effect.
> >>
> >> Signed-off-by: Juergen Gross
> >> ---
> >> V2: add oring 0x8000 to version field
> >> ---
> >> grub-core/loader/i386/linux.c | 9 +
> >> include/grub/i386/linux.h | 5 -
> >> 2 files changed, 13 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> >> index 4eab55a2d..f96309476 100644
> >> --- a/grub-core/loader/i386/linux.c
> >> +++ b/grub-core/loader/i386/linux.c
> >> @@ -35,6 +35,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >
> > Probably this change belongs to another patch.
>
> I don't think so.
You do not add anything to this header here and out of the blue you
include it in this file. So, why it is needed here?
> >> GRUB_MOD_LICENSE ("GPLv3+");
> >>
> >> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__
> >> ((unused)),
> >>prot_init_space = page_align (prot_size) * 3;
> >> }
> >>
> >> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
> >> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
> >> +lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
> >> +#endif
> >
> > It seems to me that this belongs to patch #8. Does not it?
>
> No, it is a generic new interface.
>
> It will be used by PVH first, but can be used in other environments,
> too.
I do not like this much but if you want me to get it you have to put
a blurb in the commit message why this is not enabled here. And when
it will be enabled...
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
On 18/10/2018 16:13, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
>> by passing the RSDP address via the boot parameters to Linux.
>>
>> The new protocol version 2.14 requires to set version to 0x8000 ored
>> with the actually use protocol version (the minimum of the kernel
>> supplied protocol version and the grub2 supported protocol version)
>> if 2.14 or higher are in effect.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> V2: add oring 0x8000 to version field
>> ---
>> grub-core/loader/i386/linux.c | 9 +
>> include/grub/i386/linux.h | 5 -
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
>> index 4eab55a2d..f96309476 100644
>> --- a/grub-core/loader/i386/linux.c
>> +++ b/grub-core/loader/i386/linux.c
>> @@ -35,6 +35,7 @@
>> #include
>> #include
>> #include
>> +#include
>
> Probably this change belongs to another patch.
I don't think so.
>
>> GRUB_MOD_LICENSE ("GPLv3+");
>>
>> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__
>> ((unused)),
>>prot_init_space = page_align (prot_size) * 3;
>> }
>>
>> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
>> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
>> +lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
>> +#endif
>
> It seems to me that this belongs to patch #8. Does not it?
No, it is a generic new interface.
It will be used by PVH first, but can be used in other environments,
too.
Juergen
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 01/18] xen: add some xen headers
On Thu, Oct 18, 2018 at 04:04:04PM +0200, Juergen Gross wrote: > On 18/10/2018 15:45, Daniel Kiper wrote: > > On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote: > >> In order to support grub2 in Xen PVH environment some additional Xen > >> headers are needed as grub2 will be started in PVH mode requiring to > >> use several HVM hypercalls and structures. > >> > >> Add the needed headers from Xen 4.10 being the first Xen version with > >> full (not only experimental) PVH guest support. > > > > Should not we use the latest one? 4.11? > > Hmm, that shouldn't really matter here. All used interfaces are > stable, so in case we don't need any later add-ons (which we don't) > using the 4.10 ones must be fine. OK, Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> by passing the RSDP address via the boot parameters to Linux.
>
> The new protocol version 2.14 requires to set version to 0x8000 ored
> with the actually use protocol version (the minimum of the kernel
> supplied protocol version and the grub2 supported protocol version)
> if 2.14 or higher are in effect.
>
> Signed-off-by: Juergen Gross
> ---
> V2: add oring 0x8000 to version field
> ---
> grub-core/loader/i386/linux.c | 9 +
> include/grub/i386/linux.h | 5 -
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> index 4eab55a2d..f96309476 100644
> --- a/grub-core/loader/i386/linux.c
> +++ b/grub-core/loader/i386/linux.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
Probably this change belongs to another patch.
> GRUB_MOD_LICENSE ("GPLv3+");
>
> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__
> ((unused)),
>prot_init_space = page_align (prot_size) * 3;
> }
>
> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
> +lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
> +#endif
It seems to me that this belongs to patch #8. Does not it?
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 01/18] xen: add some xen headers
On 18/10/2018 15:45, Daniel Kiper wrote: > On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote: >> In order to support grub2 in Xen PVH environment some additional Xen >> headers are needed as grub2 will be started in PVH mode requiring to >> use several HVM hypercalls and structures. >> >> Add the needed headers from Xen 4.10 being the first Xen version with >> full (not only experimental) PVH guest support. > > Should not we use the latest one? 4.11? Hmm, that shouldn't really matter here. All used interfaces are stable, so in case we don't need any later add-ons (which we don't) using the 4.10 ones must be fine. Juergen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 01/18] xen: add some xen headers
On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote: > In order to support grub2 in Xen PVH environment some additional Xen > headers are needed as grub2 will be started in PVH mode requiring to > use several HVM hypercalls and structures. > > Add the needed headers from Xen 4.10 being the first Xen version with > full (not only experimental) PVH guest support. Should not we use the latest one? 4.11? Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/1] search: Add search by GPT partition type
Hi Will,
Sorry for huge delay but I was swamped by other stuff.
Anyway, patch LGTM. Just a few nit picks below.
On Wed, Jun 20, 2018 at 04:38:08PM +0100, Will Thompson wrote:
> From: Carlo Caione
>
> Add a new search.fs_type tool to search by GPT partition type UUID.
>
> Signed-off-by: Carlo Caione
> Signed-off-by: Will Thompson
> ---
> docs/grub.texi | 14 ---
> grub-core/Makefile.core.def | 5 +++
> grub-core/commands/search.c | 69 +++-
> grub-core/commands/search_type.c | 5 +++
> grub-core/commands/search_wrap.c | 12 --
> grub-core/partmap/gpt.c | 9 +
> include/grub/gpt_partition.h | 9 -
> include/grub/partition.h | 12 ++
> include/grub/search.h| 2 +
> 9 files changed, 118 insertions(+), 19 deletions(-)
> create mode 100644 grub-core/commands/search_type.c
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 2adfa97be..17b3ff55c 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -4849,11 +4849,12 @@ unbootable. @xref{Using digital signatures}, for more
> information.
> @subsection search
>
> @deffn Command search @
> - [@option{--file}|@option{--label}|@option{--fs-uuid}] @
> + [@option{--file}|@option{--label}|@option{--fs-uuid}|@option{--fs-type}] @
> [@option{--set} [var]] [@option{--no-floppy}] name
> Search devices by file (@option{-f}, @option{--file}), filesystem label
> -(@option{-l}, @option{--label}), or filesystem UUID (@option{-u},
> -@option{--fs-uuid}).
> +(@option{-l}, @option{--label}), filesystem UUID (@option{-u},
> +@option{--fs-uuid}), or filesystem type UUID (@option{-t},
> +@option{--fs-type}).
>
> If the @option{--set} option is used, the first device found is set as the
> value of environment variable @var{var}. The default variable is
> @@ -4862,9 +4863,10 @@ value of environment variable @var{var}. The default
> variable is
> The @option{--no-floppy} option prevents searching floppy devices, which can
> be slow.
>
> -The @samp{search.file}, @samp{search.fs_label}, and @samp{search.fs_uuid}
> -commands are aliases for @samp{search --file}, @samp{search --label}, and
> -@samp{search --fs-uuid} respectively.
> +The @samp{search.file}, @samp{search.fs_label}, @samp{search.fs_uuid}, and
> +@samp{search.fs_type} commands are aliases for @samp{search --file},
> +@samp{search --label}, @samp{search --fs-type} and @samp{search --fs-uuid}
> +respectively.
Could not you use the same enumeration order like above?
> @end deffn
>
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index fc4767f19..b6c760bc1 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -1017,6 +1017,11 @@ module = {
>common = commands/search_uuid.c;
> };
>
> +module = {
> + name = search_fs_type;
> + common = commands/search_type.c;
> +};
> +
> module = {
>name = search_label;
>common = commands/search_label.c;
> diff --git a/grub-core/commands/search.c b/grub-core/commands/search.c
> index 7dd32e445..22820ec47 100644
> --- a/grub-core/commands/search.c
> +++ b/grub-core/commands/search.c
> @@ -52,8 +52,48 @@ struct search_ctx
>unsigned nhints;
>int count;
>int is_cache;
> +#ifdef DO_SEARCH_FS_TYPE
> + char *part;
> +#endif
> };
>
> +#ifdef DO_SEARCH_FS_TYPE
> +static int
> +type_part_hook (grub_disk_t disk, const grub_partition_t partition, void
> *data)
> +{
> + struct search_ctx *ctx = data;
> + char *partition_name, *guid, *dev_name;
> + int found = 0;
> +
> + partition_name = grub_partition_get_name (partition);
> + if (!partition_name)
> +return 0;
> +
> + dev_name = grub_xasprintf ("%s,%s", disk->name, partition_name);
> + grub_free (partition_name);
> +
> + guid = grub_xasprintf ("%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x",
> + grub_le_to_cpu32(partition->gpttype.data1),
> + grub_le_to_cpu16(partition->gpttype.data2),
> + grub_le_to_cpu16(partition->gpttype.data3),
> + (partition->gpttype.data4[0]),
> (partition->gpttype.data4[1]),
> + (partition->gpttype.data4[2]),
> (partition->gpttype.data4[3]),
> + (partition->gpttype.data4[4]),
> (partition->gpttype.data4[5]),
> + (partition->gpttype.data4[6]),
> (partition->gpttype.data4[7]));
> +
> + if (grub_strcasecmp (guid, ctx->key) == 0)
> +{
> + ctx->part = dev_name;
> + found = 1;
> +}
> + else
> +grub_free (dev_name);
> +
> + grub_free (guid);
> + return found;
> +}
> +#endif
> +
> /* Helper for FUNC_NAME. */
> static int
> iterate_device (const char *name, void *data)
> @@ -66,12 +106,27 @@ iterate_device (const char *name, void *data)
>name[0] == 'f' && name[1] == 'd' && name[2] >= '0' && name[2] <= '9')
> return 1;
>
> -#ifdef DO_SEARCH_FS_UUID
> +#if defined(DO_SEARCH_FS_UUID) ||
Re: [PATCH 7/9] btrfs: Add support for recovery for a RAID 5 btrfs profiles.
On Wed, Oct 17, 2018 at 09:03:58PM +0200, Goffredo Baroncelli wrote:
> On 17/10/2018 16.14, Daniel Kiper wrote:
> > On Thu, Oct 11, 2018 at 08:51:01PM +0200, Goffredo Baroncelli wrote:
> >> From: Goffredo Baroncelli
> >>
> >> Add support for recovery for a RAID 5 btrfs profile. In addition
> >> it is added some code as preparatory work for RAID 6 recovery code.
> >>
> >> Signed-off-by: Goffredo Baroncelli
> >> ---
> [...]
>
> >> +
> >> + for (failed_devices = 0, i = 0; i < nstripes; i++)
> >> +{
> >> + struct grub_btrfs_chunk_stripe *stripe;
> >> + grub_disk_addr_t paddr;
> >> + grub_device_t dev;
> >> + grub_err_t err;
> >> +
> >> + /* after the struct grub_btrfs_chunk_item, there is an array of
> >> + struct grub_btrfs_chunk_stripe */
> >
> > /* Struct grub_btrfs_chunk_stripe lives behind struct
> > grub_btrfs_chunk_item. */
>
> What about
>
> /* The struct grub_btrfs_chunk_stripe array lives behind struct
> grub_btrfs_chunk_item. */
Works for me.
> [...]
>
> >> @@ -921,17 +1061,29 @@ grub_btrfs_read_logical (struct grub_btrfs_data
> >> *data, grub_disk_addr_t addr,
> >>grub_dprintf ("btrfs", "reading laddr 0x%" PRIxGRUB_UINT64_T "\n",
> >> addr);
> >>
> >> - for (i = 0; i < redundancy; i++)
> >> + if (!is_raid56)
> >
> > Why not "if (is_raid56)"? I asked about that earlier. Please change
> > this if and of course code below. It will be much easier to read. And
> > you do not need curly brackets for for loop after else.
>
> Frankly speaking I don't see any problem having a if (!...). However I
> update the code as your request, hoping to speedup this patch set
OK, it works. However, if you have "else" below then I think that it is
more natural to drop "!" here. If you would not have else I would not
complain. Well, because it would not make sense to do so... :-)))
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 2/2] loader/i386/linux: report UEFI secure boot status to the Linux kernel
On Wed, Oct 17, 2018 at 06:01:46PM +, Ignat Korchagin wrote:
> Linux kernel from 4.11 has secure_boot member as part of linux_kernel_params.
> Currently, GRUB does not populate it, so the kernel reports
> "Secure boot could not be determined" on boot. We can populate it in EFI mode,
> so the kernel "knows" the status.
>
> Signed-off-by: Ignat Korchagin
> ---
> grub-core/loader/i386/linux.c | 54
> ++-
> include/grub/i386/linux.h | 14 +--
> 2 files changed, 65 insertions(+), 3 deletions(-)
>
> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> index 4eab55a2d..7016974a6 100644
> --- a/grub-core/loader/i386/linux.c
> +++ b/grub-core/loader/i386/linux.c
> @@ -396,6 +396,57 @@ grub_linux_boot_mmap_fill (grub_uint64_t addr,
> grub_uint64_t size,
>return 0;
> }
>
> +#ifdef GRUB_MACHINE_EFI
> +
> +/* from
> https://github.com/rhboot/shim/blob/b953468e91eac48d2e3817f18cd604e20f39c56b/lib/guid.c#L39
> */
Just mention that this comes from UEFI shim project. This should suffice.
> +#define GRUB_EFI_SHIM_LOCK_GUID \
> + { 0x605dab50, 0xe046, 0xe046, { 0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b,
> 0x23 }}
This is not Linux specific. Could you add this to
include/grub/efi/api.h (Hmmm... I do not see better place)?
And I am working on patchset which will this too.
So, I will avoid some code shuffling.
> +
> +/* mostly taken from
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/firmware/efi/libstub/secureboot.c?h=linux-4.18.y=a7012bdbdf406bbaa4e3de0cc3d8eb0faaacbf93#n37
Stable version number will suffice here.
> + except for the case, when "SecureBoot" variable is not found, because
> + grub_efi_get_variable does not report EFI_STATUS to the caller */
So, I would like to ask you to change grub_efi_get_variable()
accordingly (same for grub_efi_get_variable_with_attributes()). This will
not be a big effort. It is called in a few places only. And I think that
it should work like get_efi_var() in Linux kernel. So, EFI status should
be returned and it should get pointer to variable store, e.g. _boot.
And please add comment in the following way:
/*
*
...
*
*/
> +static grub_uint8_t
> +grub_efi_secureboot_mode (void)
> +{
> + grub_efi_guid_t efi_var_guid = GRUB_EFI_GLOBAL_VARIABLE_GUID;
> + grub_size_t efi_var_size = 0;
> + grub_efi_uint32_t attr = 0;
> + grub_uint8_t *secure_boot;
> + grub_uint8_t *setup_mode;
> + grub_uint8_t *moksb_state;
> + grub_uint8_t secureboot_mode = LINUX_EFI_SECUREBOOT_MODE_UNKNOWN;
> +
> + secure_boot = grub_efi_get_variable ("SecureBoot", _var_guid,
> _var_size);
> + setup_mode = grub_efi_get_variable ("SetupMode", _var_guid,
> _var_size);
> + efi_var_guid = GRUB_EFI_SHIM_LOCK_GUID;
> + moksb_state = grub_efi_get_variable_with_attributes ("MokSBState",
> _var_guid, _var_size, );
Please move these two lines...
> + if (!secure_boot || !setup_mode)
> +goto fail;
> +
> + if ((*secure_boot == 0) || (*setup_mode == 1))
> +secureboot_mode = LINUX_EFI_SECUREBOOT_MODE_DISABLED;
> + else
> +secureboot_mode = LINUX_EFI_SECUREBOOT_MODE_ENABLED;
...here.
> + if (moksb_state)
> +{
> + if (!(attr & GRUB_EFI_VARIABLE_RUNTIME_ACCESS) && *moksb_state == 1)
> +secureboot_mode = LINUX_EFI_SECUREBOOT_MODE_DISABLED;
> +}
Curly brackets are not needed here.
> +fail:
> + if (moksb_state)
> +grub_free (moksb_state);
> + if (setup_mode)
> +grub_free (setup_mode);
> + if (secure_boot)
> +grub_free (secure_boot);
> +
> + return secureboot_mode;
> +}
> +#endif
> +
> static grub_err_t
> grub_linux_boot (void)
> {
> @@ -574,6 +625,7 @@ grub_linux_boot (void)
> grub_efi_uintn_t efi_desc_size;
> grub_size_t efi_mmap_target;
> grub_efi_uint32_t efi_desc_version;
> +ctx.params->secure_boot = grub_efi_secureboot_mode ();
> err = grub_efi_finish_boot_services (_mmap_size, efi_mmap_buf, NULL,
>_desc_size, _desc_version);
> if (err)
> @@ -760,7 +812,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__
> ((unused)),
>
>linux_params.code32_start = prot_mode_target + lh.code32_start -
> GRUB_LINUX_BZIMAGE_ADDR;
>linux_params.kernel_alignment = (1 << align);
> - linux_params.ps_mouse = linux_params.padding10 = 0;
> + linux_params.ps_mouse = linux_params.padding11 = 0;
>
>len = sizeof (linux_params) - sizeof (lh);
>if (grub_file_read (file, (char *) _params + sizeof (lh), len) !=
> len)
> diff --git a/include/grub/i386/linux.h b/include/grub/i386/linux.h
> index 60c7c3b5e..4d20abb2e 100644
> --- a/include/grub/i386/linux.h
> +++ b/include/grub/i386/linux.h
> @@ -87,6 +87,12 @@ enum
> GRUB_VIDEO_LINUX_TYPE_SIMPLE = 0x70/* Linear framebuffer without any
> additional functions. */
>};
>
> +/* Possible values for Linux secure_boot kernel parameter */
> +#define LINUX_EFI_SECUREBOOT_MODE_UNSET0
> +#define
Re: [PATCH v2 1/2] efi: add function to read EFI variables with attributes
On Wed, Oct 17, 2018 at 06:01:45PM +, Ignat Korchagin wrote:
May I ask you to add a few words here why this change is needed.
> Signed-off-by: Ignat Korchagin
> ---
> grub-core/kern/efi/efi.c | 13 +++--
> include/grub/efi/efi.h | 4
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/grub-core/kern/efi/efi.c b/grub-core/kern/efi/efi.c
> index 708581fcb..5f7d1478f 100644
> --- a/grub-core/kern/efi/efi.c
> +++ b/grub-core/kern/efi/efi.c
> @@ -224,7 +224,16 @@ grub_efi_set_variable(const char *var, const
> grub_efi_guid_t *guid,
>
> void *
> grub_efi_get_variable (const char *var, const grub_efi_guid_t *guid,
> -grub_size_t *datasize_out)
> + grub_size_t *datasize_out)
> +{
> + return grub_efi_get_variable_with_attributes (var, guid, datasize_out,
> NULL);
> +}
> +
> +void *
> +grub_efi_get_variable_with_attributes (const char *var,
> + const grub_efi_guid_t *guid,
> + grub_size_t *datasize_out,
> + grub_efi_uint32_t *attributes)
Please put grub_efi_get_variable_with_attributes() before
grub_efi_get_variable().
> {
>grub_efi_status_t status;
>grub_efi_uintn_t datasize = 0;
> @@ -260,7 +269,7 @@ grub_efi_get_variable (const char *var, const
> grub_efi_guid_t *guid,
>return NULL;
> }
>
> - status = efi_call_5 (r->get_variable, var16, guid, NULL, , data);
> + status = efi_call_5 (r->get_variable, var16, guid, attributes, ,
> data);
>grub_free (var16);
>
>if (status == GRUB_EFI_SUCCESS)
> diff --git a/include/grub/efi/efi.h b/include/grub/efi/efi.h
> index 2c6648d46..727722797 100644
> --- a/include/grub/efi/efi.h
> +++ b/include/grub/efi/efi.h
> @@ -77,6 +77,10 @@ grub_err_t EXPORT_FUNC (grub_efi_set_virtual_address_map)
> (grub_efi_uintn_t memo
> void *EXPORT_FUNC (grub_efi_get_variable) (const char *variable,
> const grub_efi_guid_t *guid,
> grub_size_t *datasize_out);
> +void *EXPORT_FUNC (grub_efi_get_variable_with_attributes) (const char
> *variable,
> + const
> grub_efi_guid_t *guid,
> + grub_size_t
> *datasize_out,
> + grub_efi_uint32_t
> *attributes);
Same here.
If you do everything which I have asked for you can add
Reviewed-by: Daniel Kiper
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
