[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2

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: 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

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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]