Am 07.01.2014 13:43, schrieb Peter Maydell: > On 7 January 2014 12:33, Andreas Färber <afaer...@suse.de> 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
