[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/4] x86/microcode: Improve documentation and parsing for ucode=
On 17.01.2020 20:06, Eslam Elnikety wrote: > On 20.12.19 10:53, Jan Beulich wrote: >> On 19.12.2019 22:08, Eslam Elnikety wrote: >>> On 18.12.19 12:49, Jan Beulich wrote: >>>> On 18.12.2019 02:32, Eslam Elnikety wrote: >>>>> Decouple the microcode referencing mechanism when using GRUB to that >>>>> when using EFI. This allows us to avoid the "unspecified effect" of >>>>> using `<integer> | scan` along xen.efi. >>>> >>>> I guess "unspecified effect" in the doc was pretty pointless - such >>>> options have been ignored before; in fact ... >>>> >>>>> With that, Xen can explicitly >>>>> ignore those named options when using EFI. >>>> >>>> ... I don't see things becoming any more explicit (not even parsing >>>> the options was quite explicit to me). >>>> >>> >>> I agree that those options have been ignored so far in the case of EFI. >>> The documentation contradicts that however. The documentation: >>> * says <integer> has unspecified effect. >>> * does not mention anything about scan being ignored. >>> >>> With this patch, it is explicit in code and in documentation that both >>> options are ignored in case of EFI. >> >> But isn't it rather that ucode=scan could (and hence perhaps should) >> also have its value on EFI? >> > > I do not see "ucode=scan" applicable in anyway in the case of EFI. In > EFI, there are not "modules" to scan through, but rather the efi config > points exactly to the microcode blob. What would be wrong with the EFI code to also inspect whatever has been specified with ramdisk= if there was no ucode= ? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |