On Mon, Sep 02, 2019 at 07:27:35PM +0200, Laszlo Ersek wrote:
> On 09/02/19 12:21, Stefan Hajnoczi wrote:

Thank you for explaining!

> Of course the question is what we *want* here. The above targets the
> case when a user specifically wants to access virtio-fs *from within*
> UEFI (including the UEFI boot manager, the UEFI shell, and UEFI
> applications, such as grub2-efi).
> 
> 
> Other goals can be imagined. For example, the following goal is slightly
> different: "I want a guest kernel running on virtio-fs, and that guest
> kernel should find a UEFI environment underneath itself". This use case
> should be covered right now, because OVMF supports kernel / initramfs /
> cmdline via fw_cfg already. You would launch OVMF from pflash (like
> always), and instruct QEMU to load the kernel / initramfs / cmdline into
> fw_cfg from files located within the virtio-fs directory tree. OVMF
> would fetch the kernel / initramfs / cmdline from fw_cfg -- note: *no*
> firmware-level access to virtio-fs --, OVMF would launch the kernel, and
> the kernel would use its own smart driver for talking to virtio-fs. The
> kernel would also find a UEFI environment.
> 
> This would eliminate shim/grub2 from the picture. For some cases, that
> could be seen as a benefit. For other cases, as a limitation; for
> example, if you needed Secure Boot with the Machine Owner Key management
> that shim implements.

I think the existing -kernel/-initrd/-append feature is enough for the
time being and firmware virtio-fs support is not urgent.  However, I can
also imagine cases where end-users are unable to set QEMU command-line
options because they don't have access to the virtualization management
layer, but would still like to configure virtio-fs boot from within the
VM.

Stefan

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Virtio-fs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virtio-fs

Reply via email to