qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] KVM call minutes for Feb 8
Date: Sun, 13 Feb 2011 17:56:30 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]