[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.3 development update, and stock-taking

>>> On 17.01.13 at 12:12, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 17/01/13 09:09, Jan Beulich wrote:
>>>>> On 16.01.13 at 18:55, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
>>> * Xen EFI boot
>>>   - Signature checking for dom0 kernel / initrd?
>>>   status: No owner.
>>>   prognosis: Probably not for 4.4
>> This is already in the tree (c/s 26262:b62bd62b2683). Nothing else
>> should be necessary on the hypervisor side if the shim is to be used.
>> But of course pv-ops Linux continues to lack EFI support altogether.
> OK, so I think the description needs an update, then.  For Xen to be 
> fully featured, I think it would need all of the following:
> * An EFI-bootable dom0 (this should be done, right?)

"Done" in the sense of todo for pvops (our kernels have been able
to for quite a long while).

> * dom0 able to make use of EFI run-time services

Indirectly, through hypercalls.

> * Xen able to use EFI boot-time services (?)

Sure, that's how things work. Otherwise we wouldn't boot at
all from EFI. The one extra thing that some people had asked
for was to be able to also properly boot Xen via grub.efi.

> * Xen able to detect the existence of a signed Linux binary, and leave 
> EFI boot-time services enabled for dom0 to use when appropriate

No. We can't leave bot services enabled, and we also don't
need to. The model is that only the Dom0 kernel binary needs
validation at the boot loader level. Everything else will be
done in the kernel (including initrd validation, or really the
parts of it that need validation).

> * dom0 able to use boot-time EFI services and disable them when done

As above - that's not even an option.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.