Re: [Xen-devel] [PATCH] misc/xenmicrocode: Upload /lib/firmware/<some blob> to the hypervisor

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/01/2015 20:12, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 29, 2015 at 06:34:23PM +0000, Andrew Cooper wrote:
>> <snip>
>> Getting this conversation back on topic.
>>
>> The current state of play in Xen is this:
>>
>> * Boot time microcode loading exists (by scanning uncompressed cpio
>> multiboot modules) and should be safe to use.
> Please note that it does require passing in 'ucode=scan' on the Xen
> command line and does not do it automatically. It would be nice
> if that was automatic..

If there is an efficent way for Xen to identify compressed or non-cpio
boot modules and skip them (I have not inspected the code sufficiently
to know), it is perhaps the kind of option we should consider enabling
by default.

>> * The facility for runtime microcode loading exists (via privileged
>> hypercall), but is unsafe to use at present, especially if virtual
>> machines are running.  There are several steps which can be taken to
>> make it safer to use.
>>
>>
>> There is a plausible usecase for runtime microcode loading for people
>> who wish to take that risk, and as such, xenmicrocode is useful utility
>> to have, but it should probably not be available by default until we
>> believe the hypervisor side of the interface avoids the known potholes.
> Aren't these issues the same if we had an runtime microcode
> implementation (I am referring to the xen-microcode driver that
> Jeremy wrote once and some distros have in their kernel). The loading
> of microcode is done the same was as baremetal via 'rescan' interface.

Correct.  Any use of the hypercall mechanism is currently susceptible to
the potholes identified previously in this thread, and therefore unsafe
for use in practice.  This includes the classic-xen kernel driver, and
this new userspace utility.  Having the dom0 kernel issue the hypercall
as a result of its own boot time microcode patching has fewer potholes
to trip over, than later when domUs have been booted.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel