Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props

[Andreas Färber]

Am 07.01.2014 13:43, schrieb Peter Maydell:
> On 7 January 2014 12:33, Andreas Färber <address@hidden> wrote:
>> Am 16.12.2013 10:33, schrieb Peter Maydell:
>>> Anyway, I don't actively object to this series. I just think
>>> Anthony's going in the wrong direction which is why I haven't
>>> been particularly eager to actively mark it as reviewed-by me
>>> either...
>>
>> Sorry for not taking the time to reply to these concerns earlier. I
>> thought it was self-speaking that the enterprise Linux distributors
>> among us want a safeguard to avoid customers from crashing a
>> long-running VM with some avoidable device_add.
> 
> Sure. I think the right way to do that is to only allow
> them to plug in devices that are truly pluggable (ie which
> are on some pluggable bus like PCI or USB), rather than
> this way round, which is trying to blacklist devices rather
> than whitelist bus types.
> 
> In short, we shouldn't be trying to cram all of "hotplug",
> "I want an extra PCI card in my VM" and "I want to do
> complete from-scratch construction of a machine model
> including wiring up all the interrupts and defining the
> memory map" into the same interface, because the flexibility
> you need for the last one of these is going to cause endless
> user errors when attempting the first two.

Agreed that there may be better solutions. But in qemu.git we do have a
lengthy, inconsistent blacklist, which is only partially honored. Markus
refactored the blacklist to be less inconsistent, less lengthy.

In particular I like that the previous/base series makes it clear not to
mark individual PHBs as no_user, something that has come up in my PReP
review. Your ARM device patches have also benefited, I believe.

Like I said, this doesn't rule out switching to a whitelist later. His
patchset has been on the list for quite a while and no one has actually
submitted code for a different solution, yourself included. So if I get
to choose between an acceptable sparrow on-list and the pigeon on the
roof ... ;)

That said, I have been sprouting the idea of, e.g., QOM'ifying qemu_irq
in-place (rather than waiting for Pin concept), which would tackle half
of the SysBus problem. QOM'ifying MemoryRegions would be the other half.
Volunteers welcome, I am still not done with QOM realize and CPUState.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg