On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote:
> 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.
>
Actually other way around. Non PC embedded systems are those that needs
this flexibility the most.
> 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).
There are many devices in qemu that accessed via isa bus on PCI and via
MMIO in other archs, so the thing you propose here is logical and
actually implemented this way in qdev.
>
> 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.
Shortcuts, shortcuts. I think this is how qemu was written initially.
"Lets put this here 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.
>
You design by packaging not functionality?
> >>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.
>
You are talking about internal chip implementation. I am talking about
functionality. Qemu also doesn't exactly has ISA bus inside.
> >>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.
Agree. We could call thous GPIO pins ad-hoc "bus" too. But I see you
point.
>
> 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
The point is that C++ is ugly language. The short code Avi sent remind
me perl (aka line noise). It is almost impossible to parse it into
what code it actually does. Most symbols are there for C++ syntax not
functionality.
> 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.
I am not sure you can write useful program with few memory allocations.
>
> 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.
>
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
