From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs Date: Wed, 24 Nov 2010 10:40:05 -0600 Message-ID: <4CED3FE5.4000801@codemonkey.ws> References: <1290595933-13122-1-git-send-email-avi@redhat.com> <1290595933-13122-3-git-send-email-avi@redhat.com> <50DD1E97-0ECD-41E6-B6F8-1D78AA4A4876@suse.de> <4CED2416.1040102@codemonkey.ws> <20101124154006.GE15111@redhat.com> <4CED344B.3030000@codemonkey.ws> <20101124161204.GF15111@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Avi Kivity , Marcelo Tosatti , kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mail-qw0-f46.google.com ([209.85.216.46]:61807 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751443Ab0KXQkg (ORCPT ); Wed, 24 Nov 2010 11:40:36 -0500 Received: by qwb7 with SMTP id 7so1038666qwb.19 for ; Wed, 24 Nov 2010 08:40:35 -0800 (PST) In-Reply-To: <20101124161204.GF15111@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/24/2010 10:12 AM, Gleb Natapov wrote: > >> Why would we specify a PIIX3 device based on a configuration file? >> There is only one PIIX3 device in the world. I don't see a lot of >> need to create arbitrary types of devices. >> >> > Why deny this flexibility from those who need it for modelling > different HW? Besides, as I said, PIIX3 is ISA bridge and this > is what class should implement. We have fw_cfg on ISA bus too > which does not exits on real HW and we may want to have other > devices. We should be able to add them without changing PIIX3 > class. > Because this flexibility is a misfeature. It's something that noone actually uses and I've never seen anyone ask to have. It introduces a PC-centric view of the world where you artificially make a bunch of devices have bus specific logic that they really don't have. If you want to go down this route, the right approach to take is to make a separate IsaMc161818a device that has a Mc16818a device with a has-a relation (i.e. composition). But I don't see the point. Just stick the Mc16818a device in the PIIX3 via composition as it exists on normal hardware and call it a day. BTW, the only reason any of this works is because of the fact that the PIIX3 does subtractive decoding which allows arbitrary ISA devices to be plugged into the ISA bus. But subtractive decoding is very expensive and on modern LPC implementations, positive decoding is used which means that the chipset has a white list of ports for devices that sit on it. PCs are simply not as architecturally clean as I think you're advocating we try to model them. >> The real world hierarchy matters when you're trying to model I/O dispatch. >> >> > Or build device path. Any time we do something not as "real HW" we > regret it later. > Right, and real HW does composition in the PIIX3 device. So let's not regret making everything an ISA device later. >> An RTC is *not* an ISA device. It may sit *behind* an ISA bus >> because the SuperIO chip happens to be on the ISA bus. But on >> modern systems, the ISA bus has disappeared in favor of the LPC but >> that doesn't fundamentally change what the RTC is. >> > Agree. This is a device sitting on the ISA bus on a PC, but it can > sit on other buses too. And it happily does so on other architectures. > It doesn't sit on the ISA bus. A SuperIO chip sits on the ISA bus and the SuperIO chip decodes the ISA bus traffic and dispatches approriately. On the PIIX3, the SuperIO chip is part of the chipset. An ISA transaction isn't necessary to talk to the RTC--it would simply be too expensive to do this because of subtractive decoding. >> The problem with what you describe is that there are far fewer >> devices that actually sit on busses than what QEMU tries to model >> today. >> > All devices sit on some buses. > That's simply not true. Let's be specific about what a bus is. A bus is a set of lines that is shared by multiple devices with some mechanism to arbitrate who's using the bus at any given time. In PCI, roughly speaking, a transaction is sent from the controller to all devices on the bus and the device that is to handle the transaction will raise it's DEVSEL line to indicate that it's handling it. But there are plenty of cases where a device is hard wired to another device. In a simple microcontroller, it's extremely common to tie a set of GPIO pins to a specific device. There's no bus here. The i8042 is another good example. The i8042 has two ps2 plugs but it's not a bus. The keyboard port takes a keyboard and the aux port takes a mouse. You can't hook up two keyboards and you can't hook up two mice. >> Because I don't think we can implement a reasonable device model >> using a garbage collected language. Garbage collection introduces >> non-determinism and in QEMU we need to ensure that when we're >> running in a VCPU context, we exit back to the guest as quickly as >> possible. >> >> > IIRC there are garbage collected languages that allow you to disable garbage > collection for certain part of the code. Yeah, but very few languages that I know of are sophisticated here. > Garbage collection can be done > while vcpu executes guest code and in proper implementation vcpu thread > should execute device model code for a very brief time and do not sleep > there. All this makes me think that garbage collection shouldn't be a > big issue for kvm userspace. But I don't see the point. If you look at my repository, there's very few memory allocations. This is largely due to the fact that I don't overly abstract busses and rely on simple composition where appropriate. Plus, with tr1::smart_pointers, you can be leak free without every worrying about explicit freeing. There are, of course, possibilities of having circular references but it's not too hard to avoid that in practice. Regards, Anthony Liguori > > -- > Gleb. >