Allowing arbitary file names on command line is setting us up for
failure: future guests will look for a specific QEMU-specified name and
will get confused finding a user file there.
We do warn but people are conditioned to ignore warnings by now,
so at best that will help users debug problem, not
On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
> OVMF uses this feature for a few flags. They are all called
> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which
> shouldn't be surprising since I seem to have reviewed every patch for
> that file):
Wait a second.
I frankly think it's overengineered, but it's already much better and if
it helps converging to a compromise why not.
Alternatives to your proposals follow:
On 17/03/2016 14:13, Michael S. Tsirkin wrote:
>
> QEMU command line:
> A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get co
On 03/16/16 19:43, Michael S. Tsirkin wrote:
> On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
>> On 03/16/16 19:15, Gabriel L. Somlo wrote:
>>> On Wed, 16 Mar 2016 at 18:50:57 +0200, Michael S. Tsirkin wrote:
On Wed, Mar 16, 2016 at 05:29:45PM +0100, Markus Armbruster wrote:
>>>
On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
> On 03/16/16 19:15, Gabriel L. Somlo wrote:
> > On Wed, 16 Mar 2016 at 18:50:57 +0200, Michael S. Tsirkin wrote:
> >> On Wed, Mar 16, 2016 at 05:29:45PM +0100, Markus Armbruster wrote:
> >>> "Michael S. Tsirkin" writes:
> >>>
> Al
On Wed, Mar 16, 2016 at 08:15:07PM +0100, Laszlo Ersek wrote:
> >> I liked (and like) the "mechanism, not
> >> policy" thing. Letting developers pass in whatever they want, for
> >> development / debugging / testing purposes, is a plus to me.
> >>
> >> Thanks
> >> Laszlo
> >
> > Could you flesh ou
On 17/03/2016 14:49, Michael S. Tsirkin wrote:
>> On 17/03/2016 14:13, Michael S. Tsirkin wrote:
>>>
>>> QEMU command line:
>>> A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get conflicts
>>>with QEMU hardware
>>
>> Alternative: no need to prepend usr/, I think.
>
> I person
On 17/03/2016 09:49, Laszlo Ersek wrote:
> On 03/16/16 21:31, Michael S. Tsirkin wrote:
>> On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
>>> OVMF uses this feature for a few flags. They are all called
>>> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which
>>>
On 03/16/16 21:31, Michael S. Tsirkin wrote:
> On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
>> OVMF uses this feature for a few flags. They are all called
>> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which
>> shouldn't be surprising since I seem to have revi
On Thu, Mar 17, 2016 at 02:30:34PM +0100, Paolo Bonzini wrote:
> I frankly think it's overengineered, but it's already much better and if
> it helps converging to a compromise why not.
Thanks, I'll think of your suggestions over the weekend. We might be able
to simplify things a bit.
> Alternativ
On 03/17/16 09:42, Gerd Hoffmann wrote:
> Hi,
>
>>> Having a mis-use of this feature become "institutionalized" over time was
>>> seen as a low/negligible risk at the time. Do we have any new reasons
>>> to worry about it ?
>>
>> OVMF uses this feature for a few flags. They are all called
>> "op
Hi,
> Alternative: fail on:
>
> - a blacklist of etc/* files including etc/system-states,
> etc/smbios/smbios-tables, etc/smbios/smbios-anchor,
> etc/reserved-memory-end, etc/pvpanic-port, etc/e820, and possibly
> etc/boot-menu-wait
I think that fails already because qemu throws an error on du
Hi,
> > Having a mis-use of this feature become "institutionalized" over time was
> > seen as a low/negligible risk at the time. Do we have any new reasons
> > to worry about it ?
>
> OVMF uses this feature for a few flags. They are all called
> "opt/ovmf/...". I followed the advice in "docs/sp
On 17/03/2016 18:17, Gerd Hoffmann wrote:
> Hi,
>
>> Alternative: fail on:
>>
>> - a blacklist of etc/* files including etc/system-states,
>> etc/smbios/smbios-tables, etc/smbios/smbios-anchor,
>> etc/reserved-memory-end, etc/pvpanic-port, etc/e820, and possibly
>> etc/boot-menu-wait
>
> I th
On 03/17/16 09:42, Gerd Hoffmann wrote:
> Hi,
>
>>> Having a mis-use of this feature become "institutionalized" over time was
>>> seen as a low/negligible risk at the time. Do we have any new reasons
>>> to worry about it ?
>>
>> OVMF uses this feature for a few flags. They are all called
>> "op
On Wed, Mar 16, 2016 at 05:29:45PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > Allowing arbitary file names on command line is setting us up for
> > failure: future guests will look for a specific QEMU-specified name and
> > will get confused finding a user file there.
>
On Thu, Mar 17, 2016 at 10:40:24AM +0100, Paolo Bonzini wrote:
>
>
> On 17/03/2016 09:49, Laszlo Ersek wrote:
> > On 03/16/16 21:31, Michael S. Tsirkin wrote:
> >> On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
> >>> OVMF uses this feature for a few flags. They are all called
> >>>
On 17/03/2016 15:17, Michael S. Tsirkin wrote:
> On Thu, Mar 17, 2016 at 02:55:52PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 17/03/2016 14:49, Michael S. Tsirkin wrote:
On 17/03/2016 14:13, Michael S. Tsirkin wrote:
>
> QEMU command line:
> A. -fw-cfg RFQDN/PATH prepends usr/. S
On Thu, Mar 17, 2016 at 02:28:38PM +0100, Laszlo Ersek wrote:
> On 03/17/16 11:22, Gerd Hoffmann wrote:
> > Hi,
> >
> >> Occasionally, yes.
> >>
> >> - "opt/ovmf/PcdPropertiesTableEnable" controls whether the "properties
> >
> >> - "opt/ovmf/PcdSetNxForStack" controls whether the stack is made
On Thu, Mar 17, 2016 at 02:12:56PM +0100, Paolo Bonzini wrote:
>
>
> On 17/03/2016 12:32, Michael S. Tsirkin wrote:
> > > 1) files should actually be named etc/ovmf/foo. OVMF could optionally
> > > accept both the old and the new names for a while, you would decide
> > > whether this is useful.
"Michael S. Tsirkin" writes:
> Allowing arbitary file names on command line is setting us up for
> failure: future guests will look for a specific QEMU-specified name and
> will get confused finding a user file there.
>
> We do warn but people are conditioned to ignore warnings by now,
> so at be
On Thu, Mar 17, 2016 at 08:35:25PM +0100, Paolo Bonzini wrote:
>
>
> On 17/03/2016 18:17, Gerd Hoffmann wrote:
> > Hi,
> >
> >> Alternative: fail on:
> >>
> >> - a blacklist of etc/* files including etc/system-states,
> >> etc/smbios/smbios-tables, etc/smbios/smbios-anchor,
> >> etc/reserved-m
On 03/17/16 14:30, Paolo Bonzini wrote:
> On 17/03/2016 14:13, Michael S. Tsirkin wrote:
>> OVMF:
>> Can use the compatible opt/ovmf/ for now. [snip]
>> Long term: Gradually transition OVMF to look up paths in usr/org.uefi/:
>> if nothing is found there, look up in opt/ovmf/ for ba
Top level reply, because this isn't in reply to any specific message in
the thread, more like in reply to all of them.
FW CFG's primary user is QEMU, which uses it to expose configuration
information (in the widest sense) to Firmware. Thus the name FW CFG.
FW CFG can also be used by others for t
On Wed, 16 Mar 2016 at 18:50:57 +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 16, 2016 at 05:29:45PM +0100, Markus Armbruster wrote:
> > "Michael S. Tsirkin" writes:
> >
> > > Allowing arbitary file names on command line is setting us up for
> > > failure: future guests will look for a specific
Hi,
> Occasionally, yes.
>
> - "opt/ovmf/PcdPropertiesTableEnable" controls whether the "properties
> - "opt/ovmf/PcdSetNxForStack" controls whether the stack is made
> - "opt/ovmf/X-PciMmio64Mb" controls the size of the range from which the
> In downstream, we have two more (same purpose bu
On 03/17/16 11:22, Gerd Hoffmann wrote:
> Hi,
>
>> Occasionally, yes.
>>
>> - "opt/ovmf/PcdPropertiesTableEnable" controls whether the "properties
>
>> - "opt/ovmf/PcdSetNxForStack" controls whether the stack is made
>
>> - "opt/ovmf/X-PciMmio64Mb" controls the size of the range from which the
On 17/03/2016 12:32, Michael S. Tsirkin wrote:
> > 1) files should actually be named etc/ovmf/foo. OVMF could optionally
> > accept both the old and the new names for a while, you would decide
> > whether this is useful.
>
> IOW if etc/ovmf exists, then ignore opt/ovmf? OK.
>
> > 2) in turn, b
On Thu, Mar 17, 2016 at 10:43:08AM +0100, Laszlo Ersek wrote:
> And, obviously, exposing this kind of knob with dedicated QEMU options
> is out of question.
We are moving away from dedicated options anyway.
But these could easily be machine properties, with
the benefit that there is actual valida
On Thu, Mar 17, 2016 at 02:55:52PM +0100, Paolo Bonzini wrote:
>
>
> On 17/03/2016 14:49, Michael S. Tsirkin wrote:
> >> On 17/03/2016 14:13, Michael S. Tsirkin wrote:
> >>>
> >>> QEMU command line:
> >>> A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get conflicts
> >>> with QEMU
On 17/03/2016 14:35, Michael S. Tsirkin wrote:
> > We meant just two partitions of the namespace. "opt/" and non-"opt/".
> > The latter belongs to QEMU, the former belongs to everything else, and
> > the subdivision of everything else doesn't belong into QEMU. OVMF is
> > part of everything else.
On Wed, Mar 16, 2016 at 08:15:07PM +0100, Laszlo Ersek wrote:
> On 03/16/16 19:43, Michael S. Tsirkin wrote:
> > On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
> >> On 03/16/16 19:15, Gabriel L. Somlo wrote:
> >>> On Wed, 16 Mar 2016 at 18:50:57 +0200, Michael S. Tsirkin wrote:
> >>>
On Thu, Mar 17, 2016 at 03:50:08PM +0100, Paolo Bonzini wrote:
>
>
> On 17/03/2016 15:17, Michael S. Tsirkin wrote:
> > On Thu, Mar 17, 2016 at 02:55:52PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 17/03/2016 14:49, Michael S. Tsirkin wrote:
> On 17/03/2016 14:13, Michael S. Tsirkin wrote
Hi,
> So, "user defined files" exist so that users can control "stuff" with
> them, without QEMU's knowledge. OVMF is "stuff". Just because it's
> firmware, it remains "stuff". Whatever Gabriel wants to control with
> such fw_cfg files in the guest, is also "stuff".
Well, non-firmware stuff was
On 03/16/16 19:15, Gabriel L. Somlo wrote:
> On Wed, 16 Mar 2016 at 18:50:57 +0200, Michael S. Tsirkin wrote:
>> On Wed, Mar 16, 2016 at 05:29:45PM +0100, Markus Armbruster wrote:
>>> "Michael S. Tsirkin" writes:
>>>
Allowing arbitary file names on command line is setting us up for
failu
On Thu, Mar 17, 2016 at 11:09:24AM +0100, Markus Armbruster wrote:
> Top level reply, because this isn't in reply to any specific message in
> the thread, more like in reply to all of them.
>
> FW CFG's primary user is QEMU, which uses it to expose configuration
> information (in the widest sense)
36 matches
Mail list logo
