Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 11:49 AM, Gleb Natapov wrote:
> On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote:
>    
> > On 02/10/2011 11:10 AM, Gleb Natapov wrote:
> >      
> > > On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
> > >        
> > > > On 02/10/2011 10:07 AM, Gleb Natapov wrote:
> > > >          
> > > > > So what if it is easier, it doesn't mean it is correct thing to do.
> > > > >            
> > > > If we spend the next 10 years trying to do the "correct thing" for
> > > > some arbitrary definition of correct, that's not terribly useful.
> > > >          
> > > Changing direction by 180 every 2 years even less useful.
> > >        
> > If we think through what we are doing and have a coherent
> > architecture before changing direction, then we won't have this
> > problem.
> >
> >      
> I'd like to believe this :)
>
>    
> > > > It's really simple actually.  Let's do the least clever thing and
> > > > model how hardware actual works.  Once we have that, we can try to
> > > > be better than real hardware (if it's possible).
> > > >          
> > > I think out understanding on how HW actually works is very different.
> > > You are placing to much value on were device resides physically, for me
> > > it is completely unimportant detail. Not worth even mentioning.
> > >        
> > No, I place value on how things are modelled in the real world.
> >      
> Real world (physical HW) have consideration not relevant for our
> software emulation. Such as cost, physical dimension, power consumption
> and many other I am sure I missed.
>
>    
> > There simply aren't PC's out there that lack an RTC so I have no
> > interest in jumping through hoops in QEMU to make it possible to do
> > this without modifying QEMU code.  It might sound nice to a
> > developer but it's of absolutely no use to users.
> >
> >      
> RTC is not good example. HPET suppose to replace it (and PIT too).

HPET's embed RTCs to provide support for legacy implementations.   This 
is extremely good example of where our modelling breaks down.  Take a 
close look at how the HPET and RTC emulations interact for an example of 
why we'd be much better off just implementing an RTC within an HPET.

>   AFAIC
> there are PCs without RTC already.

RTC also provides CMOS functionality and no PC can boot without CMOS.  
So no, there's nothing we'd consider a PC today that doesn't have an RTC.

>   Good example would be PIC or IOAPIC
> device and then I would agree with you that it is not worth it to make
> it possible to create x86 machine without them from command line if it
> means extra complexity. But how have you jumped from this to "lets make usb
> mandatory"?
>    

USB is mandatory in the PIIX3 but the only significant difference 
between the piix2 and piix3 is the addition of USB.  Consequentially, 
the main difference between an i440fx and i440bx is the use of a piix2 
vs. a piix3.  So if you really want to create the same PC we have today 
w/o USB, the right way to do it would be to have:

-device i440,model=fx   // with USB
-device i440,model=bx  // w/o USB


> > No, we don't. It's possible to have an 'rtc=off' option but I'm
> > tremendously opposed to doing this.  Arbitrary composition is not a
> > useful goal IMHO.
> >      
> IMHO is different. We should support composition where it makes sense.
> For PIC-less x86 it doesn't make it. For usb-less or even ide-less it
> does.
>    

The right way to do a USB-less PC is to have an option to create an i440bx.

An IDE-less PC is a bit more difficult because IDE is really baked into 
the concept of a PC.  Chances are, there are more than a few guests out 
there that would have issues from there being no IDE bus present.

> >      
> > >   So why do you like -device i440fx over what we have now?
> > >        
> > Because I don't think tools like libvirt should be doing device
> > composition to create an i440fx-like chipset.  I think the current
> > path we're on is pushing too much logic that belongs in QEMU into
> > the management stack.
> >      
> I can agree with that. But from this it doesn't follow that we should
> get rid of composition. We shouldn't push composition of common HW to
> libvirt. Looking at libvirt command line I do not think we do it though.
> Typical libvirt command line specifies disks, networks, usb, vga. How
> -device i440fx will simplified that? Well usb could be omitted (but not
> -usbdevice table), disks are not property of i440fx so they will stay,
> since user may want to use virtio controller (which is not part of
> i440fx) this should stay too. Network obviously will have to be
> specified by libvirt too, vga may go to i440fx, but since libvirt
> supports qxl we will have to have a way to disable default vga and
> enable qxl instead. So will we really simplify libvirt's life by
> introducing -device i440fx?
>    

libvirt also uses -no-defaults which prevents much of the PC's machine 
init from creating anything but stuff that really belongs in the main 
chipset.

But I bet if you asked 5 different QEMU developers what belongs in 
machine init and what the role of -no-defaults is, you'd get different 
answers.

OTOH, skipping any notion of machine and explicitly creating a chipset 
provides a very consistent architecture.

> >      
> > > In current speak you propose will be implement by using i440fx machine
> > > type. Qdev will build it for you.
> > >        
> > If you had an i440fx machine type, that had no non-optional
> > components added, and you could specify options to the machine type,
> > yes.  But I think you'll agree that there's no reason to not just
> > treat the i440fx as a device.
> >      
> I do not agree. There is not such device as i440fx. This is just
> packaging.
>    

Nope, that's definitely not true.  There's quite a bit of logic that is 
in the silicon that is not part of PIIX3.

Regards,

Anthony Liguori