On 2/19/21 3:46 PM, Connor Kuehl wrote: > On 2/18/21 9:48 AM, Philippe Mathieu-Daudé wrote: >> On 2/18/21 4:16 PM, Connor Kuehl wrote: >>> Connor Kuehl (2): >>> sev: use explicit indices for mapping firmware error codes to strings >>> sev: add missing firmware error conditions >>> >>> target/i386/sev.c | 48 ++++++++++++++++++++++++----------------------- >>> 1 file changed, 25 insertions(+), 23 deletions(-) >> >> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> > > Thank you! :-) > >> To avoid this problem in future (new error code added on the Linux >> kernel side) would it be acceptable to add a 3rd patch as: >> >> -- >8 -- >> diff --git a/target/i386/sev.c b/target/i386/sev.c >> index 0f414df02f3..e086d3198e8 100644 >> --- a/target/i386/sev.c >> +++ b/target/i386/sev.c >> @@ -155,9 +155,12 @@ sev_platform_ioctl(int fd, int cmd, void *data, int >> *error) >> static const char * >> fw_error_to_str(int code) >> { >> + QEMU_BUILD_BUG_ON(SEV_RET_SECURE_DATA_INVALID + 1 == SEV_RET_MAX); >> + >> if (code < 0 || code >= SEV_FW_MAX_ERROR) { >> return "unknown error"; >> } >> + assert(sev_fw_errlist[code]); >> >> return sev_fw_errlist[code]; >> } >> --- >> >> which triggers a build error if scripts/update-linux-headers.sh >> added another sev_ret_code entry? >> > > I like this a lot. Should I send a v2 of the series with a third patch > like this or shall I wait to see if these patches get applied then send > something like this as a follow up patch?
Since I've the patch locally I'll simply send it.
