From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Sun, 13 Feb 2011 10:56:30 -0600 Message-ID: <4D580D3E.3000300@codemonkey.ws> References: <20110208155557.GM6198@x200.localdomain> <4D51B1C9.3080507@codemonkey.ws> <4D526D0D.9020507@codemonkey.ws> <4D52A86A.1030407@codemonkey.ws> <4D52F20A.7070009@codemonkey.ws> <4D539800.3070802@codemonkey.ws> <4D53BE22.3050706@redhat.com> <4D57FB12.5060703@codemonkey.ws> <4D57FF2E.7020001@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Blue Swirl , Chris Wright , Markus Armbruster , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mail-yi0-f46.google.com ([209.85.218.46]:39800 "EHLO mail-yi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754604Ab1BMQ4g (ORCPT ); Sun, 13 Feb 2011 11:56:36 -0500 Received: by yib18 with SMTP id 18so1738324yib.19 for ; Sun, 13 Feb 2011 08:56:35 -0800 (PST) In-Reply-To: <4D57FF2E.7020001@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/13/2011 09:56 AM, Avi Kivity wrote: > 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. Yeah, I wasn't implying that it was. > 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. Exactly. Or better yet, blah is a config file that contains [device "nb"] driver=i440fx [device "sb"] driver=piix3 chipset=nb [device "ioapic"] driver=ioapic chipset=sb [device "cpu"] driver=cpu ioapic=ioapic northbridge=nb >> >>>> >>>> 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. If we can move away from Bus abstraction and to a simpler interface mechanism, then we can express peer relationships by just having bidirection references. IOW: -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus I don't think modelling each CPU makes sense. We should probably just model all cpus in a single device for the sake of simplicity. Regards, Anthony Liguori