Re: [PATCH v1] docs: Expand the "BIOS bootloader" documentation for domainCaps

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

 



On Wed, Sep 11, 2019 at 05:40:02PM +0200, Michal Privoznik wrote:
> On 9/11/19 4:34 PM, Kashyap Chamarthy wrote:

[...]

> > diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in
> > index bc99d378567a553afe682bc522e7a753b2d805fc..a8d970934df2c0ce8c41eb4958c94fbdf96ef8e0 100644
> > --- a/docs/formatdomaincaps.html.in
> > +++ b/docs/formatdomaincaps.html.in
> > @@ -127,7 +127,7 @@
> >         <value>/usr/share/OVMF/OVMF_CODE.fd</value>
> >         <enum name='type'>
> >           <value>rom</value>
> > -        <value>pflash</value>
> > +        <value>pflapsh</value>
> 
> This looks like a unintended change.

Oops, indeed; sorry.

[...]

> > +      <code>firmware</code> attribute of the <code>os</code> element in
> > +      the domain XML. The presence of this enum means libvirt is capable
> > +      of the so-called firmware auto-selection feature. And the listed
> > +      firmware values represent the accepted input in the domain
> > +      XML. Note that the <code>firmware</code> enum reports only those
> > +      values for which a firmware "descriptor file" exists on the host
> > +      -- a small JSON document that describes details about a given UEFI
> > +      binary on the host, e.g. the fimware binary path, its
> 
> FW descriptors can describe a BIOS image too.

Yes; missed to be careful here.

> > +      architecture, supported machine type, NVRAM template, etc. This
> > +      ensures that the reported values won't cause a failure on guest
> > +      boot.
> 
> 
> >  (The firmware "descriptor files" are typically shipped
> > +      Linux distribution as part of the firmware package,
> > +      e.g. EDK2/OVMF.)
> 
> This is not exactly true. FW descriptors are shipped by qemu actaully. 

Yes and no.

QEMU upstream ships them in the pc-bios/descriptors.

However, most major distributions Debian, Ubuntu and Fedora[*] ship them
as part of edk2/edk2-ovmf packages.  Because (quoting from the commit
message from here[*]):

[quote]

  - Distributions providing their own EDK2 packages would not include
    the descriptors from upstream QEMU, even if they otherwise package
    QEMU.  That's beause the descriptor files in QEMU match the firmware
    bundled with QEMU -- but the firmware images in the distros' own
    EDK2 packages are different.  So, if a distro provides an EDK2
    package, then the same EDK2 package should offer matching
    descriptors.  QEMU offers descriptors (soon) because QEMU
    technically distributes edk2 firmware binaries (soon).  [Where
    "soon" == QEMU 4.1] 

  - In Fedora, we need to ship them [the "descriptor files"] as part of
    the EDK2 package, because Fedora throws away all the firmware files
    that QEMU bundles, because we're [Fedora] required to rebuild
    everything from pristine source.

[/quote]


[*] https://src.fedoraproject.org/rpms/edk2/c/674b3c8a27a8

> But also, I don't think users need to bother - their distro will
> install it when updating qemu package.

Yeah.  I just wanted to add a hint for those wondering "where do I find
these files".

> ACK to the rest and pushed. Thanks for taking care of this.

Thanks for the quick review and merge.

-- 
/kashyap

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux