On Tue, Sep 08, 2020 at 08:03:46AM +0100, Daniel P. Berrangé wrote:
On Tue, Sep 08, 2020 at 08:37:03AM +0200, Martin Kletzander wrote:
On Mon, Sep 07, 2020 at 03:38:23PM +0100, Daniel P. Berrangé wrote:
> On Mon, Sep 07, 2020 at 04:20:02PM +0200, Michal Privoznik wrote:
> > On 9/7/20 3:57 PM, Martin Kletzander wrote:
> > > On Mon, Sep 07, 2020 at 03:48:16PM +0200, Michal Privoznik wrote:
> > > > Even though this was brought up in upstream discussion [1] it
> > > > missed my patches: users should prefer <oemStrings/> over fwcfg.
> > > > The reason is that fwcfg is considered somewhat internal to QEMU
> > > > and it has limited number of slots and neither of these applies
> > > > to <oemStrings/>.
> > > >
> > > > While I'm at it, I'm fixing the example too (because it contains
> > > > incorrect element name) and clarifying sysfs/ exposure.
> > > >
> > > > 1: https://www.redhat.com/archives/libvir-list/2020-May/msg00957.html
> > > >
> > > > Reported-by: Laszlo Ersek <ler...@redhat.com>
> > > > Signed-off-by: Michal Privoznik <mpriv...@redhat.com>
> > > > ---
> > > > docs/formatdomain.rst | 14 +++++++++-----
> > > > 1 file changed, 9 insertions(+), 5 deletions(-)
> > > >
> >
> >
> > > It's nice that you say that, but people who would like to use fw_cfg for
> > > passing
> > > in a huge blob, which is saved in a file, will read this, go to
> > > <oemStrings/>
> > > and see that there is no way to pass a file as an input.  Should that be
> > > dealt
> > > with somehow?  Or would that be discouraged as well?
> >
> > Unfortunately, QEMU doesn't allow reading OEM strings from a file (at least
> > quick glance over hw/smbios/smbios.c doesn't show any signs it's allowed).
>
> Indeed, that is an RFE I've never got around to
>

Do you mean RFE for QEMU or libvirt?

Both.

Are there any limitations for the oemStrings?  Libvirt could read the file and
pass the data to QEMU as it is not something that is supposed to be writeable or
shareable.  I understand it could be the first time we do something like this,
but it might not be that bad of a precedence.

The problem is the size of the command line you end up with.

Good point.

You need to have QEMU support for reading from the file.


Or from an FD, ideally.

Just so we are on the same page, I'm not against this patch, I just want to save
our users the frustration that I, myself, experienced so many times.  There's
something deep hurting when you finally find exactly what you're looking for,
only to learn that it is deprecated with another option which does not provide
the same functionality.  Sure, you can have a start hook that reads a file and
changes the data, etc.  But you get the point.  At least we could mention that?


Regards,
Daniel
--
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Attachment: signature.asc
Description: PGP signature

Reply via email to