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

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/13/2011 12:08 PM, Gleb Natapov wrote:
> On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
>    
>>>> qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
>>>> ioapic,id=ioapic,chipset=sb -device
>>>> cpu,ioapic=ioapic,northbridge=nb
>>>>
>>>> Is not all that unreasonable and presents a fully functioning PC.
>>>>          
>>> Sure.  And -M blah is a shortcut.
>>>        
>> Exactly.  Or better yet, blah is a config file that contains
>>
>> [device "nb"]
>> driver=i440fx
>>
>>      
> You are trying to model how particular (very ancient) HW looked like,
> instead of emulating guest visible functionality, but is dead end since
> things are changing constantly. Northbridge functionality moves onto
> cpu for instance. What CPU i440fx was designed for? Pentium?  What if
> user runs QEMU with emulated CPU that in real life has internal memory
> controller? Does you config have sense for such setup? Should we allow
> to specify only Pentium CPU since this is how real HW worked?
>    

Yes, how we structure the device tree will change over time.  If users 
have to specify this stuff, we've already failed to start with.

The i440fx is definitely guest visible.  And yes, a guest could look at 
freak out that an i440fx is in use with a non-Pentium class CPU.  We 
cheat here, and it works just fine.

>> [device "sb"]
>> driver=piix3
>>      
> And piix3 refers to piix3.cfg which describe devices that present on the
> chipset.
>    

I disagree in this case that it's the best thing to do, but in general, 
yeah, we should provide a mechanism to have essentially device tree 
macros such that one high level device represents a larger tree of 
devices.  This would be a good mechanism to support the concept of machines.

But I don't think we should rely on having this tomorrow as doing this 
well is going to be challenging.

>> chipset=nb
>>
>> [device "ioapic"]
>> driver=ioapic
>> chipset=sb
>>      
> Here, for instance, IOAPIC is included in a chipset for a long time
> now. Why user should care that piix3 didn't have it. How this detail
> changes qemu functionality? If it doesn't why should we expose it?
>    

Yeah, I'd be inclined to push the ioapic into the chipset here except it 
may be useful to have multiple ioapics at some point down the road.

Yes, we're exposing gory details of the device model.  No, I don't have 
a problem with that.

>> [device "cpu"]
>> driver=cpu
>> ioapic=ioapic
>>      
> Why ioapic here? Doesn't cpu talks to ioapic via northbridge?
>    

The i440fx is the northbridge.  For the i440fx, the I/O apic is a 
separate chip.

Regards,

Anthony Liguori