|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? |
Date: | Tue, 03 Aug 2010 15:49:00 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
On 08/03/2010 03:00 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 10:22:22PM +0300, Avi Kivity wrote:On 08/03/2010 10:13 PM, Richard W.M. Jones wrote:On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:libguestfs does not depend on an x86 architectural feature. qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should discourage people from depending on this interface for production use.I really don't get this whole thing where we must slavishly emulate an exact PC ...This has two motivations: - documented interfaces: we suck at documentation. We seldom document. Even when we do document something, the documentation is often inaccurate, misleading, and incomplete. While an "exact PC" unfortunately doesn't exist, it's a lot closer to reality than, say, an "exact Linux syscall interface". If we adopt an existing interface, we already have the documentation, and if there's a conflict between the documentation and our implementation, it's clear who wins (well, not always). - preexisting guests: if we design a new interface, we get to update all guests; and there are many of them. Whereas an "exact PC" will be seen by the guest vendors as well who will then add whatever support is necessary.On the other hand we end up with stuff like only being able to add 29 virtio-blk devices to a single guest. As best as I can tell, this comes from PCI
No, this comes from us being too clever for our own good and not following the way hardware does it.
All modern systems keep disks on their own dedicated bus. In virtio-blk, we have a 1-1 relationship between disks and PCI devices. That's a perfect example of what happens when we try to "improve" things.
, and this limit required a bunch of hacks when implementing virt-df. These are reasonable motivations, but I think they are partially about us: We could document things better and make things future-proof. I'm surprised by how lacking the doc requirements are for qemu (compared to, hmm, libguestfs for example).
We enjoy complaining about our lack of documentation more than we like actually writing documentation.
We could demand that OSes write device drivers for more qemu devices -- already OS vendors write thousands of device drivers for all sorts of obscure devices, so this isn't really much of a demand for them. In fact, they're already doing it.
So far, MS hasn't quite gotten the clue yet that they should write device drivers for qemu :-) In fact, noone has.
Regards, Anthony Liguori
Rich.
[Prev in Thread] | Current Thread | [Next in Thread] |