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

Avi Kivity
2011-02-13T15:56:40Z

On 02/13/2011 05:38 PM, Anthony Liguori wrote:
>>
>>>
>>> 2) get rid of the entire concept of machines. Creating a i440fx is
>>> essentially equivalent to creating a bare machine.
>>
>> No, it's not. The 440fx does not include an IOAPIC, for example.
>> There may be other optional components, or differences in wiring,
>> that make two machines with i440fx not identical.
>
>
> The IOAPIC is basically the only other component and I view it as part
> of the CPU interface to the chipset.

But it isn't. The IOAPIC is not per-core or per-socket. It's strictly
board level. It's a board interface to the cpu.

>
> But still, if we're creating a machine from scratch:
>
> 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.

>
>>>
>>> 4) model the CPUs as devices that take a pointer to a host
>>> controller, for x86, the normal case would be giving it a pointer to
>>> i440fx.
>>>
>>
>> Surely the connection is via a bus? An x86 cpu talks to the bus, and
>> there happens to be an 440fx north bridge at the end of it. It could
>> also be a Q35 or something else.
>
> I see being on a bus as really just taking a pointer to an interface.
> So yes, the i440fx would implement a PentiumCpuInterface or something
> like that and the CPU would take a pointer to a PentiumCpuInterface[1].
>
> This is part of why having proper polymorphism is important. We need
> it in order to be able to express concepts like interfaces.

The CPUs and northbridge are peers on the system bus. However, this
isn't something good to model, since it keeps changing without any guest
software impact.

--
error compiling committee.c: too many arguments to function