From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47320 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmUyk-0004BV-GU for qemu-devel@nongnu.org; Fri, 20 Aug 2010 13:02:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmUyi-0002Bl-Ra for qemu-devel@nongnu.org; Fri, 20 Aug 2010 13:02:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48392) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmUyi-0002Bd-F5 for qemu-devel@nongnu.org; Fri, 20 Aug 2010 13:02:04 -0400 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup References: <4C6D86F9.3010602@codemonkey.ws> <4C6D98E7.9020109@codemonkey.ws> <4C6DA75D.40303@codemonkey.ws> Date: Fri, 20 Aug 2010 19:01:48 +0200 In-Reply-To: <4C6DA75D.40303@codemonkey.ws> (Anthony Liguori's message of "Thu, 19 Aug 2010 16:51:25 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , "Liu >> \"Liu, Jinsong\"" , Paul Brook , Avi Kivity , qemu-devel Anthony Liguori writes: > 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. While that might be useful, I don't quite see what makes CPUs so special that they need to be kept out of qdev. Could be just my ignorance, of course. >>> requirement to sit on a bus. A UART16650A does not sit on bus. It sits on >>> a card and is wired to the ISA bus or is sometimes wired directly to pins 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. You > really want the virtio PCI layer to only use PCI functions and > specifically to interact with PCI concepts that don't exist in other > busses (like IO regions and config space). However, you also want the > ability to interact with a virtio device through a well defined > interface that isn't PCI specific. > > The only way to do this right now is having a bus with a single > device. I've been working on the serial device, and what this > requires is having an ISASerialDevice which is-a ISADevice. The > ISASerialDevice has-a > SerialBus and the SerialBus contain a single SerialDevice which is-a > DeviceState. It needs to be a SerialBusDevice, not just a DeviceState, actually. > But the ISASerialDevice has to assume that the SerialBus contains only > a single child because it needs to connect the GPIO out from the > SerialDevice 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. What's the *practical* benefit of splitting up ISASerialDevice into UART-ISA adapter and the UART proper? The "bus" sitting between the two would be trivial. If we do that everywhere, we'll end up with many different, trivial buses. >> 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 the >>> 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. You cannot just 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. I don't think hot plugging should exist at the > qdev level. Hot plugging is a very bus specific concept with very bus > specific restrictions. For 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. So there's > really no way you could conceptually hot plug a multi-function virtio > adapter although you can pretty trivially create one statically. I think it's fair to say that qdev doesn't currently get hot-plugging right. >>>>> 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. An x86 CPU cannot exist >>> without a local APIC and a local APIC cannot exist without an x86 CPU. The >>> two are fundamentally tied together. That's a pretty convincing argument for why a LAPIC should not be separated from its CPU in qdev. It should be part of the CPU qdev, or maybe a child of it. >> 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. There is also an > I/O APIC which exists outside of the CPU core. The local APIC was > introduced with SMP support. > > The PIC and IO APIC totally make sense to be modelled as qdev. > >>> It'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. The PIC is programmed via pio > at a fixed location. There is only one PIC and it interacts with the > system just like all other devices. IOW, there is no reference to > CPUState. > > When you look at the local APIC (apic.c) however, you see that it's > the only device in the tree that actually interacts with a CPUState. > The notion of cpu_get_current_apic() is a good example of the tricks > needed to make this work. > > The local APIC is a cpu feature, not a device. A bit like the UART is a ISASerialDevice feature?