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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
