Paolo Bonzini writes:
> On 10/12/2015 12:06, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 09/12/2015 10:30, Markus Armbruster wrote:
My current working assumption is that passing &error_fatal to
memory_region_init_ram() & friends is okay even in realize() methods and
>>
On 10/12/2015 12:06, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 09/12/2015 10:30, Markus Armbruster wrote:
>>> My current working assumption is that passing &error_fatal to
>>> memory_region_init_ram() & friends is okay even in realize() methods and
>>> their supporting code, exce
On 10/12/2015 12:21, Dr. David Alan Gilbert wrote:
> I guess the use of abort() could tell us
> that - however it's a really big assumption that in an OOM case we'd
> be able to dump the information.
If it's not OOM, but just a multi-gigabyte allocation, we should.
Paolo
* Markus Armbruster (arm...@redhat.com) wrote:
> Paolo Bonzini writes:
>
> > On 09/12/2015 10:30, Markus Armbruster wrote:
> >> My current working assumption is that passing &error_fatal to
> >> memory_region_init_ram() & friends is okay even in realize() methods and
> >> their supporting code, e
On 12/10/15 10:22, Markus Armbruster wrote:
> Laszlo Ersek writes:
>
>> I've been following this discussion with great interest.
>>
>> My opinion should not be considered, because I won't be turning my
>> opinion into new code, or an agreement to support / maintain code. :)
>>
>> My opinion is th
Paolo Bonzini writes:
> On 09/12/2015 10:30, Markus Armbruster wrote:
>> My current working assumption is that passing &error_fatal to
>> memory_region_init_ram() & friends is okay even in realize() methods and
>> their supporting code, except when the allocation can be large.
>
> I suspect a lot
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" writes:
>>
>> > * Markus Armbruster (arm...@redhat.com) wrote:
>> >> In general, code running withing a realize() method should not exit() on
>> >> error. Instad, errors should be prop
Laszlo Ersek writes:
> I've been following this discussion with great interest.
>
> My opinion should not be considered, because I won't be turning my
> opinion into new code, or an agreement to support / maintain code. :)
>
> My opinion is that
> - every single allocation needs to be checked rig
On 09/12/2015 14:12, Dr. David Alan Gilbert wrote:
>> > Even if we don't, we should use &error_abort, not &error_fatal
>> > (programmer error---due to laziness---rather than user error).
>> > &error_fatal should really be restricted to code that is running very
>> > close to main().
> No, we used
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 9 December 2015 at 10:29, Dr. David Alan Gilbert
> wrote:
> > (OK, to be honest I think we should protect every allocation - but I do
> > have sympathy with the complexity/testing arguments).
>
> My view on this is that Linux overcommits, so
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 09/12/2015 10:30, Markus Armbruster wrote:
> > My current working assumption is that passing &error_fatal to
> > memory_region_init_ram() & friends is okay even in realize() methods and
> > their supporting code, except when the allocation can
On 09/12/2015 10:30, Markus Armbruster wrote:
> My current working assumption is that passing &error_fatal to
> memory_region_init_ram() & friends is okay even in realize() methods and
> their supporting code, except when the allocation can be large.
I suspect a lot of memory_region_init_ram()s
On 12/09/15 12:47, Peter Maydell wrote:
> On 9 December 2015 at 10:29, Dr. David Alan Gilbert
> wrote:
>> (OK, to be honest I think we should protect every allocation - but I do
>> have sympathy with the complexity/testing arguments).
>
> My view on this is that Linux overcommits, so the actual
On 9 December 2015 at 10:29, Dr. David Alan Gilbert wrote:
> (OK, to be honest I think we should protect every allocation - but I do
> have sympathy with the complexity/testing arguments).
My view on this is that Linux overcommits, so the actual likely
way that "oops, out of memory" will manifest
On 12/09/15 11:29, Dr. David Alan Gilbert wrote:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" writes:
>>
>>> * Markus Armbruster (arm...@redhat.com) wrote:
In general, code running withing a realize() method should not exit() on
error. Instad, errors shou
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> In general, code running withing a realize() method should not exit() on
> >> error. Instad, errors should be propagated through the realize()
> >> method.
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> In general, code running withing a realize() method should not exit() on
>> error. Instad, errors should be propagated through the realize()
>> method. Additionally, the realize() method should fail cleanly,
>>
* Markus Armbruster (arm...@redhat.com) wrote:
> In general, code running withing a realize() method should not exit() on
> error. Instad, errors should be propagated through the realize()
> method. Additionally, the realize() method should fail cleanly,
> i.e. carefully undo its side effects suc
In general, code running withing a realize() method should not exit() on
error. Instad, errors should be propagated through the realize()
method. Additionally, the realize() method should fail cleanly,
i.e. carefully undo its side effects such as wiring of interrupts,
mapping of memory, and so fo
19 matches
Mail list logo
