From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36420 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmXSn-00017q-3Z for qemu-devel@nongnu.org; Fri, 20 Aug 2010 15:41:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmXFH-0005pQ-TX for qemu-devel@nongnu.org; Fri, 20 Aug 2010 15:27:21 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:57190) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmXFH-0005pM-PW for qemu-devel@nongnu.org; Fri, 20 Aug 2010 15:27:19 -0400 Received: by qyk31 with SMTP id 31so2517397qyk.4 for ; Fri, 20 Aug 2010 12:27:19 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C6DA75D.40303@codemonkey.ws> References: <4C6D86F9.3010602@codemonkey.ws> <4C6D98E7.9020109@codemonkey.ws> <4C6DA75D.40303@codemonkey.ws> From: Blue Swirl Date: Fri, 20 Aug 2010 19:26:59 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Liu >> \"Liu, Jinsong\"" , Avi Kivity , qemu-devel , Paul Brook On Thu, Aug 19, 2010 at 9:51 PM, Anthony Liguori wr= ote: > On 08/19/2010 04:21 PM, Blue Swirl wrote: >>> >>> Should CPUs appear in the QEMU device tree? >>> >> >> They have several properties that should be user visible. >> > > Sure, but that's an argument for having some of the qdev features (like > variant properties) be consumable outside of qdev. Or rather, separate qdev from SysBus. I don't think either makes much sense= . >>> requirement to sit on a bus. =C2=A0A UART16650A does not sit on bus. = =C2=A0It sits >>> on >>> a card and is wired to the ISA bus or is sometimes wired directly to pi= ns >>> on >>> a CPU on a SoC. >>> >> >> Or all buses should be unified, so all devices could be wired into any >> board. >> > > But that defeats the notion of having bus level interfaces. =C2=A0You rea= lly want > the virtio PCI layer to only use PCI functions and specifically to intera= ct > with PCI concepts that don't exist in other busses (like IO regions and > config space). =C2=A0However, you also want the ability to interact with = a virtio > device through a well defined interface that isn't PCI specific. True, but if a device uses dedicated bus interfaces, it can't be used on other buses. It might be possible to construct the devices so that most of the code is bus agnostic and only a shim interfaces with the bus of the day, which should be close to what you proposed in the earlier serial example. One way to model pure devices could be something like chip select line, address bus (possibly truncated) and data bus (also possibly narrowed). Any way, I think the current model is pretty much fine as is. > The only way to do this right now is having a bus with a single device. > =C2=A0I've been working on the serial device, and what this requires is h= aving an > ISASerialDevice which is-a ISADevice. =C2=A0The ISASerialDevice has-a Ser= ialBus > and the SerialBus contain a single SerialDevice which is-a DeviceState. > > But the ISASerialDevice has to assume that the SerialBus contains only a > single child because it needs to connect the GPIO out from the SerialDevi= ce > to the ISA irq that's assigned. > > It would be a whole lot simpler to break the "all devices sit on busses" > assumption that we have today and simply have the ISASerialDevice has-a > SerialDevice with no additional layers of bus indirection. > >> IIRC I tried also that approach when I worked on this patch set but >> there were some problems. Maybe with header file conflicts, or >> qemu_irq was not available to CPU code. >> > > Okay, I'll queue it up for a future day. > >>> Because not all devices on the sysbus can be hot added so if you made t= he >>> bus hotpluggable, it would basically defeat the point of even marking a >>> bus >>> as not supporting hot plug. >>> >>> IOW, the whole bus is either hot pluggable or not. =C2=A0You cannot jus= t say >>> that >>> device X can be hotplugged but nothing else. >>> >> >> Perhaps the hotplugging system in QEMU needs some rethinking instead. >> Many real devices are not hot pluggable. >> > > That's probably fair. =C2=A0I don't think hot plugging should exist at th= e qdev > level. =C2=A0Hot plugging is a very bus specific concept with very bus sp= ecific > restrictions. =C2=A0For instance, with PCI, you can only plug at slot > granularities whereas today, we don't really model multi-function devices= as > anything more than a set of unrelated devices. =C2=A0So there's really no= way you > could conceptually hot plug a multi-function virtio adapter although you = can > pretty trivially create one statically. Maybe PCI could introduce an indirection: cards. They could contain any number of qdev devices. >>>>> I think the options are to allow non-bus devices (like the APIC) or >>>>> make >>>>> the >>>>> APIC a special case that's part of the CPU emulation. >>>>> >>>>> >>>> >>>> No. There could also be a new hotpluggable bus type, CPUBus, one >>>> instance between each CPU and APIC. Or SysBusWithHotPlug. But I don't >>>> see how that would be different from SysBus. >>>> >>>> >>> >>> Neither approach maps well to real hardware. =C2=A0An x86 CPU cannot ex= ist >>> without a local APIC and a local APIC cannot exist without an x86 CPU. >>> =C2=A0The >>> two are fundamentally tied together. >>> >> >> What about 486? Or 82489? >> > > Don't confuse the local APIC with the PIC or the I/O APIC. > > The local APIC has always existed in the CPU core. =C2=A0There is also an= I/O > APIC which exists outside of the CPU core. =C2=A0The local APIC was intro= duced > with SMP support. No, 82489 was an external local APIC for 486DX. See for example Intel Multiprocessor Specification, page 3-5. > The PIC and IO APIC totally make sense to be modelled as qdev. > >>> =C2=A0It's like modelling a TLB as a >>> separate device. >>> >> >> That has surely happened in ancient times. >> > > Yes, but the programming model was different. > > Look at the PIC compared to the lapic. =C2=A0The PIC is programmed via pi= o at a > fixed location. =C2=A0There is only one PIC and it interacts with the sys= tem just > like all other devices. =C2=A0IOW, there is no reference to CPUState. > > When you look at the local APIC (apic.c) however, you see that it's the o= nly > device in the tree that actually interacts with a CPUState. =C2=A0The not= ion of > cpu_get_current_apic() is a good example of the tricks needed to make thi= s > work. > > The local APIC is a cpu feature, not a device. That is certainly one way how to handle it, but not the only one and not the most flexible. In contrast, CPUBus could have other uses like north/south bridges, caches etc. On Sparc, a CPUBus could fuse ASIs and addresses and these could be decoded by an external device. That could simplify target-sparc/op_helper.c while not messing physical address space order too much. But in my mind, what in this specific case binds local APIC tighter to the CPU than to the devices is the CR register access. We probably don't want a CRBus.