On Wed, Sep 16, 2020 at 01:31:05PM +0200, Laszlo Ersek wrote:
> On 09/16/20 11:56, Daniel P. Berrangé wrote:
> > On Wed, Sep 16, 2020 at 11:52:41AM +0200, Laszlo Ersek wrote:
> >> (5) In my opinion (which could be wrong of course), we shouldn't
> >> introduce a new command line option for this,
On 09/16/20 11:56, Daniel P. Berrangé wrote:
> On Wed, Sep 16, 2020 at 11:52:41AM +0200, Laszlo Ersek wrote:
>> Hi Erich,
>>
>> (1) this patch is really not trivial; please do not continue CC'ing
>> qemu-trivial
>>
>> (2) Please do CC people that have given you feedback previously. I
>> primarily
On Wed, Sep 16, 2020 at 11:52:41AM +0200, Laszlo Ersek wrote:
> Hi Erich,
>
> (1) this patch is really not trivial; please do not continue CC'ing
> qemu-trivial
>
> (2) Please do CC people that have given you feedback previously. I
> primarily mean Daniel and David.
>
> (3) Generally speaking,
On 09/16/20 11:52, Laszlo Ersek wrote:
> (5) In my opinion (which could be wrong of course), we shouldn't
> introduce a new command line option for this, but a new PC machine type
> property called "x-firmware-max-size".
>
> Please look at the object_class_property_add() calls in
>
Hi Erich,
(1) this patch is really not trivial; please do not continue CC'ing
qemu-trivial
(2) Please do CC people that have given you feedback previously. I
primarily mean Daniel and David.
(3) Generally speaking, please post new versions of a patch stand-alone
(not in reply to another
rcu_disable_atfork();
--
2.25.1
____________
From: McMillan, Erich
Sent: Tuesday, September 15, 2020 2:09 PM
To: qemu-devel@nongnu.org
Cc: m...@redhat.com ; marcel.apfelb...@gmail.com
; qemu-triv...@nongnu.org
Subject: Re: PATCH: Increase System Firmware Max Size
Hi
MaxCombinedFirmwareSize);
exit(1);
}
From: McMillan, Erich
Sent: Thursday, September 10, 2020 8:45 PM
To: qemu-devel@nongnu.org
Cc: m...@redhat.com ; marcel.apfelb...@gmail.com
; qemu-triv...@nongnu.org
Subject: PATCH: Increase Syste
apfelb...@gmail.com; qemu-triv...@nongnu.org; Markus Armbruster;
Philippe Mathieu-Daudé
Subject: Re: PATCH: Increase System Firmware Max Size
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 09/11/20 18:22, Dr. David Alan Gilbert wrote:
>
> > We have lots of complex hideous changes that I'm
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 09/11/20 18:22, Dr. David Alan Gilbert wrote:
>
> > We have lots of complex hideous changes that I'm never going to use but
> > seem reasonable; this is a tiny change that seems perfectly reasonable
> > both for open and closed firmware.
> > I
On 09/11/20 18:22, Dr. David Alan Gilbert wrote:
> We have lots of complex hideous changes that I'm never going to use but
> seem reasonable; this is a tiny change that seems perfectly reasonable
> both for open and closed firmware.
> I realise herding OVMF developers is tricky, but that's not a
On 09/11/20 18:21, Daniel P. Berrangé wrote:
> If OVMF maintainers want to reject
> feature proposals they have the right to do that regardless of what
> QEMU sets for max image size. As you say earlier, the existing size
> limit is already enourmous compared to what OVMF actually uses, so
> if
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 09/11/20 17:06, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> >> On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
>
> >>> I'm missing what this constant exists for - why is the
> >>> check there at all Is there
On Fri, Sep 11, 2020 at 06:06:27PM +0200, Laszlo Ersek wrote:
> On 09/11/20 17:23, Daniel P. Berrangé wrote:
>
> > I don't see why we should have this as a hard coded
> > limit that is not runtime configurable.
> >
> > IOW, why can't we keep our current default and provide a machine type
> >
On 09/11/20 17:22, McMillan, Erich wrote:
> I agree that fw has become the vendor OS, but at this point there's no
> going back.
> Utilizing a virtual platform allows us to greatly increase the security
> of our code,
> could we make this change a Qemu experimental flag, so that fw vendors could
On 09/11/20 17:23, Daniel P. Berrangé wrote:
> I don't see why we should have this as a hard coded
> limit that is not runtime configurable.
>
> IOW, why can't we keep our current default and provide a machine type
> property "firmware_max_size" which users can opt-in to setting if
> their
On 09/11/20 17:06, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
>> On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
>>> I'm missing what this constant exists for - why is the
>>> check there at all Is there something else that lives below this
>>> address that we
On Fri, Sep 11, 2020 at 04:06:02PM +0100, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
> > On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
> > > it doesn't have any pretty graphics
> > > or snazzy stuff,
> >
> > Which is arguably completely superfluous on every
org
; m...@redhat.com ;
marcel.apfelb...@gmail.com ;
qemu-triv...@nongnu.org ; Markus Armbruster
; Philippe Mathieu-Daudé
Subject: Re: PATCH: Increase System Firmware Max Size
>* Laszlo Ersek (ler...@redhat.com) wrote:
> On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
> > * La
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> >> +Markus, Dave, Phil
> >>
> >> On 09/11/20 03:45, McMillan, Erich wrote:
> >>> Hi all,
> >>>
> >>> (this is my first Qemu patch submission, please let me
On 09/11/20 10:34, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
>> +Markus, Dave, Phil
>>
>> On 09/11/20 03:45, McMillan, Erich wrote:
>>> Hi all,
>>>
>>> (this is my first Qemu patch submission, please let me know if my
>>> formatting/content needs to be fixed).
>>>
* Laszlo Ersek (ler...@redhat.com) wrote:
> +Markus, Dave, Phil
>
> On 09/11/20 03:45, McMillan, Erich wrote:
> > Hi all,
> >
> > (this is my first Qemu patch submission, please let me know if my
> > formatting/content needs to be fixed).
> > We have a need for increased firmware size,
+Markus, Dave, Phil
On 09/11/20 03:45, McMillan, Erich wrote:
> Hi all,
>
> (this is my first Qemu patch submission, please let me know if my
> formatting/content needs to be fixed).
> We have a need for increased firmware size, currently we are building Qemu
> with the following change to
Hi all,
(this is my first Qemu patch submission, please let me know if my
formatting/content needs to be fixed).
We have a need for increased firmware size, currently we are building Qemu with
the following change to test our Uefi Firmware and it works well for us. Hope
that this change can be
23 matches
Mail list logo
