search for: uefi_flag_secure_boot_requir

This is only lightly tested. In particularly I only tested that the non-secure-boot path still works. I didn't test it on RHEL 7.3 yet because I haven't got enough free disk space for these giant source *.ova files :-( Will try to give that a go later. Rich.

...arget_firmware = + let uefi_firmware = + match target_firmware with + | TargetBIOS -> None + | TargetUEFI -> Some (find_uefi_firmware guestcaps.gcaps_arch) in + let secure_boot_required = + match uefi_firmware with + | Some { Uefi.flags = flags } + when List.mem Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED flags -> true + | _ -> false in + match target_firmware, secure_boot_required with + | TargetUEFI, true -> 3 (* q35 + UEFI + secure boot *) + | TargetUEFI, _ -> 2 (* q35 + UEFI *) + (* 1 is q35 + SeaBIOS *) + | _, _ -> 0 (* i440fx + SeaBIOS *) + (* Generate the .meta file...

..._xml ?pool source target_buses guestcaps match target_firmware with | TargetBIOS -> None | TargetUEFI -> Some (find_uefi_firmware guestcaps.gcaps_arch) in - let secure_boot_required = - match uefi_firmware with - | Some { Uefi.flags = flags } - when List.mem Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED flags -> true - | _ -> false in - (* Currently these are required by secure boot, but in theory they - * might be independent properties. - *) - let machine_q35 = secure_boot_required in + let machine, secure_boot_required = + match guestcaps.gcaps_machine, uefi_firmware with +...

...nerator/UEFI.ml +++ b/generator/UEFI.ml @@ -52,6 +52,12 @@ let firmware = [ "/usr/share/edk2/ovmf/OVMF_VARS.fd", []; + "x86_64", + "/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd", + None, + "/usr/share/edk2/ovmf/OVMF_VARS.fd", + [ "UEFI_FLAG_SECURE_BOOT_REQUIRED" ]; + "x86_64", "/usr/share/qemu/ovmf-x86_64-code.bin", None, -- 2.17.1

...are = > + match target_firmware with > + | TargetBIOS -> None > + | TargetUEFI -> Some (find_uefi_firmware guestcaps.gcaps_arch) in > + let secure_boot_required = > + match uefi_firmware with > + | Some { Uefi.flags = flags } > + when List.mem Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED flags -> true > + | _ -> false in > + match target_firmware, secure_boot_required with > + | TargetUEFI, true -> 3 (* q35 + UEFI + secure boot *) > + | TargetUEFI, _ -> 2 (* q35 + UEFI *) > + (* 1 is q35 + SeaBIOS *) > + | _, _ -> 0 (* i440fx + SeaBIOS *)...

First version was posted here: https://www.redhat.com/archives/libguestfs/2016-August/thread.html#00100 This is semantically the same as the first version. However I've split the patch up into two parts. In the first part, I factor out the UEFI paths so now they are created by the generator and written in the library and v2v/ directory directly, instead of the complex business of having a C

...tr); -/* uefi.c */ -struct uefi_firmware { - const char *code; /* code file (NULL = end of list) */ - const char *code_debug; /* code file with debugging msgs (may be NULL)*/ - const char *vars; /* vars template file */ - int flags; /* various flags, see below */ -#define UEFI_FLAG_SECURE_BOOT_REQUIRED 1 /* secure boot (see RHBZ#1367615) */ -}; -extern struct uefi_firmware guestfs_int_uefi_i386_firmware[]; -extern struct uefi_firmware guestfs_int_uefi_x86_64_firmware[]; -extern struct uefi_firmware guestfs_int_uefi_aarch64_firmware[]; - /* These functions are used internally by the CLEANUP_* m...

...git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml index fbe90eeaa..4b36ffb8e 100644 --- a/v2v/create_libvirt_xml.ml +++ b/v2v/create_libvirt_xml.ml @@ -86,10 +86,6 @@ let create_libvirt_xml ?pool source target_buses guestcaps | Some { Uefi.flags = flags } when List.mem Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED flags -> true | _ -> false in - (* Currently these are required by secure boot, but in theory they - * might be independent properties. - *) - let machine_q35 = secure_boot_required in let smm = secure_boot_required in (* We have the machine features of the guest when it...

...l b/v2v/create_libvirt_xml.ml > index fbe90eeaa..4b36ffb8e 100644 > --- a/v2v/create_libvirt_xml.ml > +++ b/v2v/create_libvirt_xml.ml > @@ -86,10 +86,6 @@ let create_libvirt_xml ?pool source target_buses guestcaps > | Some { Uefi.flags = flags } > when List.mem Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED flags -> true > | _ -> false in > - (* Currently these are required by secure boot, but in theory they > - * might be independent properties. > - *) > - let machine_q35 = secure_boot_required in > let smm = secure_boot_required in > > (* We have th...

Starting with 5.2.0, libvirt has a way to select the firmware by specifying its type, provided configuration files for the firmware are shipped. Currently we start the appliance as UEFI if any of the firmware are found, so instead we can try to just set the firmware type iff: - the libvirt autoselection works - the 'efi' firmware is available The only behaviour change is that the default

I got a little way into this. The two attached patches are preliminary work. My proposed split is: libguestfs.git common -> git submodule libguestfs-common.git generator/ lib/ all language bindings C based tools (eg. virt-df, virt-edit, guestfish) guestfs-tools.git common -> git submodule libguestfs-common.git

..."type", JSON.String firmware_type; + ] in + + (match target_firmware with + | TargetBIOS -> () + | TargetUEFI -> + let uefi_firmware = find_uefi_firmware guestcaps.gcaps_arch in + let flags = + List.map ( + function + | Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED -> "secure_boot_required" + ) uefi_firmware.Uefi.flags in + + let uefi = ref [ + "code", JSON.String uefi_firmware.Uefi.code; + "vars", JSON.String uefi_firmware.Uefi.vars; + "flags", JSON.List (json_list_of_string_l...

..."type", JSON.String firmware_type; + ] in + + (match target_firmware with + | TargetBIOS -> () + | TargetUEFI -> + let uefi_firmware = find_uefi_firmware guestcaps.gcaps_arch in + let flags = + List.map ( + function + | Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED -> "secure_boot_required" + ) uefi_firmware.Uefi.flags in + + let uefi = ref [ + "code", JSON.String uefi_firmware.Uefi.code; + "vars", JSON.String uefi_firmware.Uefi.vars; + "flags", JSON.List (json_list_of_string_l...

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

...tput_qemu.ml +++ b/v2v/output_qemu.ml @@ -57,7 +57,7 @@ object | TargetUEFI -> Some (find_uefi_firmware guestcaps.gcaps_arch) in let secure_boot_required = match uefi_firmware with - | Some { Uefi.flags = flags } + | Some { Uefi.flags } when List.mem Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED flags -> true | _ -> false in (* Currently these are required by secure boot, but in theory they @@ -85,7 +85,7 @@ object (match uefi_firmware with | None -> () - | Some { Uefi.code = code } -> + | Some { Uefi.code } -> if secure_boot_requi...

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

Per my previous email: https://www.redhat.com/archives/libguestfs/2017-September/msg00203.html I'd like to talk about requiring a more modern version of the OCaml compiler. These commits show some of the code changes which would be possible with OCaml >= 3.12 [which it turns out we already require by accident] and also with OCaml >= 4.02. The latter is my favoured option. Rich.

This is just the utilities part of the patch series from: https://www.redhat.com/archives/libguestfs/2017-June/msg00103.html I believe this addresses everything raised in comments on that patch series. Rich.

This turned out to be rather more involved than I thought. We have lots of utility functions, spread all over the repository, with not a lot of structure. This moves many of them under common/ and structures them so there are clear dependencies. This doesn't complete the job by any means. Other items I had on my to-do list for this change were: - Split up mllib/common_utils into: -

This is a combination of: https://www.redhat.com/archives/libguestfs/2017-June/msg00046.html [PATCH 00/12] Refactor utility functions. plus: https://www.redhat.com/archives/libguestfs/2017-June/msg00023.html [PATCH v3 00/19] Allow APIs to be implemented in OCaml. with the second patches rebased on top of the utility refactoring, and some other adjustments and extensions. This passes