qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
Date: Wed, 08 Jan 2014 09:00:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Andreas Färber <address@hidden> writes:

> Am 08.01.2014 04:07, schrieb Peter Crosthwaite:
>> On Wed, Jan 8, 2014 at 2:59 AM, Paolo Bonzini <address@hidden> wrote:
>>> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
>>>>     aarch64     akita           info qtree crashes
>>>>     aarch64     borzoi          info qtree crashes
>>>>     aarch64     spitz           info qtree crashes
>>>>     aarch64     terrier         info qtree crashes
>>>>     aarch64     tosa            info qtree crashes
>>>>     arm         akita           info qtree crashes
>>>>     arm         borzoi          info qtree crashes
>>>>     arm         spitz           info qtree crashes
>>>>     arm         terrier         info qtree crashes
>>>>     arm         tosa            info qtree crashes
>>>>     cris        axis-dev88      info qtree crashes
>>>
>>> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>>> 2013-06-18).   Should probably be reverted.
>>>
>> 
>> Prefer not, under no reasonable definition is NAND a sysbus device.
>> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
>> qtree that TYPE_DEVICE is not?
>
> Not fully aware of the context yet, but my response to complaints about
> info qtree, whether here or from Igor, will be to simply drop it.
>
> Anthony has clearly stated on a KVM call that we should not design code
> to please info qtree but to use the new QOM paradigms. If people don't
> listen, we must take qdev stuff away for people to realize it - 2.0 is
> certainly a good point in time. And I had already informally posted a
> qom-tree Python script to the list that I can turn into a formal patch.
>
> My plan was to first extend the qom-test to assure that all machines'
> properties can be qom-get'ed crash-free, but we can of course skip such
> safety precautions if that helps avoid weird workarounds.
>
> As a reminder, the CPU is not a SysBus device either (ICC on x86, device
> elsewhere) and I certainly don't want to make it one, especially now
> that we're about to refactor AddressSpaces.

No matter how much you want to retire a monitor command, until you've
retired it, a crash bug is a crash bug.  Crash bugs need fixing a.s.a.p.
In this case, we have a safe and quick fix: revert the (recent!) patch
that broke it.

I object to retiring "info qtree" before a replacement is available.  In
my personal opinion, a bunch of python scripts is not a replacement.
They may be okay for developers, but hardly for users.  We need a HMP
command to inspect the machine.  Device IDs, in particular, but also
other properties.

"info qtree" has always been incomplete, because it can only show
qdevified devices.  Restricting it further to the subtree rooted at the
main system bus that is connected via qbus edges could be okay.  If it
helps, which isn't obvious to me, but I'm happy to leave that to you.

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]