Re: [Qemu-devel] Re: [PATCH v2 9/9] Add -kvm option

[Gerd Hoffmann]

On 10/12/09 18:31, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
> > On 10/12/09 16:04, Anthony Liguori wrote:
> > > Gerd Hoffmann wrote:
> > > > -M $machine gives you a barebone machine with all core devices which
> > > > belong to it. You can't easily remove and/or replace devices.
> > > > Especially not something central as the IRQ controller. But also no
> > > > other core components, i.e. you wouldn't stick a piix4 ide controller
> > > > into a Q35 machine. Just say 'no'.
> > >
> > > This seems fundamentally flawed to me. If you cannot remove a device
> > > from a machine using command line options, then how do we support
> > > something like -net none?
> >
> > '-net none' does not remove a nic. It makes qemu not add the default nic.
>
> qemu should not have the concept of a default nic.

Well, right now it has (likewise for serial, vga, ...).  And it causes 
problems with the qdev way of managing devices, so we have to find a way 
to deal with it.

Right now the default devices are tied to a command line switch, i.e. in 
case there isn't a -serial switch specified qemu will add a default 
serial device, even in case one was added via -device isa-serial.

> Instead, if you
> choose the pc machine type, by default you get an e1000. I think it's
> also reasonable to get a USB controller too along with the balloon
> driver and anything else we think a user could benefit from.

Hmm.  It makes sense to have a usable default or example configuration.

I don't think the machine type should be that though.  IMO the machine 
type should be more like a chipset, i.e. the current pc type should 
include all core stuff (pit, pic, apic, rtc, ...) and the piix devices 
(host bridge, isa bridge, apci controller, ide controller, usb 
controller) but nothing else.

> If you give devices well known ids, then changing a default device is
> not really that big of a deal. It involves removing the device and
> adding a new device with that same device id.

Might be workable for anything added via -device, because you could do 
the operations in QemuOpts space, before actually creating qdev device 
instances.  And the user could switch the nic type via
'-set device.defaultnic.driver=rtl8139' then.

I still don't like the concept though.  Configuring a second nic would 
be different from configuring the first nic, because for the first 
you'll modify the default device, the second is added instead.  libvirt 
folks will hate us for doing this.

> For platform devices, like the interrupt controller/pic, the same
> principle could be applied to switch out a userspace irqchip/pit with
> the kvm kernel implementations.

Doesn't fly.  You can't simply add interrupt controllers via -device. 
They are tied way to much with the other core devices.

cheers,
  Gerd