qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH] remove pieces of source code


From: Jan Kiszka
Subject: Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
Date: Fri, 29 May 2009 12:20:59 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Daniel P. Berrange wrote:
> On Fri, May 29, 2009 at 11:08:38AM +0200, Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>
>>>  o There is no alternative for non-Linux users and folks with non-VT/SVM
>>> hardware
>> The non-HVM argument will become widely irrelevant (for desktops) very
>> soon. The non-Linux issue will likely persist - unless someone feels so
>> much pain to write some KVM for those platforms. But as long as there is
>> a kqemu version that builds and works for them, I think we should keep
>> QEMU's support. But it should no longer be a first-class citizen: off by
>> default, factored out into more hooks, maybe even de-optimized where it
>> blocks development or increases the maintenance effort of QEMU.
> 
> The non-HVM argument will always exist, and could actually get worse
> if lots of vendors start shipping with embedded hypervisors, such that
> your 'real' OS is already virtualized behind your back. That said I do 

Nested virtualization like this would have been one nice-to-have via
kqemu. And in fact, most of our development took place inside kvm. But
the performance was worse than qemu inside kvm, at least for our use cases.

That said, there might be scenarios where kqemu inside whatever
hypervisor provides better performance than emulation, but I can only
recommend to evaluate this carefully. The overhead of virtualizing
kqemu's monitor activities can be enormous.

> agree with you - we're still better off killing/deprecating kqemu and 
> using any spare effort to improve nested-SVM/VT support which is a more 
> useful long term feature.
> 

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

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