[Qemu-devel] POLL: Why do you use kqemu?

[Qemu-devel] POLL: Why do you use kqemu?

[Anthony Liguori]

I'm curious to know who all out there is using kqemu and why they are
using it.  Please take a moment to fill out the following poll if you
use kqemu.  Having actual data as to why people are using kqemu may help
figure out the best way to replace it in the future.

http://www.micropoll.com/akira/mpview/604126-172373

I'll post the results in a few weeks.

Thanks,

Anthony Liguori

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Anton D Kachalov]

Good day, Anthony.

There is one point missed: "I do not use kqemu".
Just to have statistics weight for the other side.

On 04.06.2009 01:57, Anthony Liguori wrote:
> I'm curious to know who all out there is using kqemu and why they are
> using it.  Please take a moment to fill out the following poll if you
> use kqemu.  Having actual data as to why people are using kqemu may help
> figure out the best way to replace it in the future.
>
> http://www.micropoll.com/akira/mpview/604126-172373
>    

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Johannes Schindelin]

Hi,

On Thu, 4 Jun 2009, Anton D Kachalov wrote:

> There is one point missed: "I do not use kqemu". Just to have statistics 
> weight for the other side.

I think that is totally beside the point.  The question is if it is worth 
to continue to support kqemu.  And frankly, for that I could not care less 
if there are people _not_ using kqemu if there are enough that _do_ use 
kqemu to merit a continuation.

Hth,
Dscho

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Gerd Hoffmann]

On 06/05/09 02:44, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 4 Jun 2009, Anton D Kachalov wrote:
>
>> There is one point missed: "I do not use kqemu". Just to have statistics
>> weight for the other side.
>
> I think that is totally beside the point.  The question is if it is worth
> to continue to support kqemu.  And frankly, for that I could not care less
> if there are people _not_ using kqemu if there are enough that _do_ use
> kqemu to merit a continuation.

A poll for both users and non-users would make sense IMHO.  It should 
include reasons for both groups though, i.e. like this:

I use kqemu because:
   [ ] old hardware
   [ ] *BSD host
   ....

I don't use kqemu because:
   [ ] using kvm instead
   [ ] using virtualbox instead
   [ ] doesn't work stable for me
   ...

cheers,
   Gerd

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Tomasz Chmielewski]

Gerd Hoffmann wrote:
> On 06/05/09 02:44, Johannes Schindelin wrote:
>> Hi,
>>
>> On Thu, 4 Jun 2009, Anton D Kachalov wrote:
>>
>>> There is one point missed: "I do not use kqemu". Just to have statistics
>>> weight for the other side.
>>
>> I think that is totally beside the point.  The question is if it is worth
>> to continue to support kqemu.  And frankly, for that I could not care 
>> less
>> if there are people _not_ using kqemu if there are enough that _do_ use
>> kqemu to merit a continuation.
> 
> A poll for both users and non-users would make sense IMHO.  It should 
> include reasons for both groups though, i.e. like this:
> 
> I use kqemu because:
>   [ ] old hardware
>   [ ] *BSD host
>   ....
> 
> I don't use kqemu because:
>   [ ] using kvm instead
>   [ ] using virtualbox instead
>   [ ] doesn't work stable for me
>   ...

And what should I answer if I both use kqemu on some (old) hardware, and 
kvm otherwise?


-- 
Tomasz Chmielewski
http://wpkg.org

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Anton D Kachalov]

On 05.06.2009 12:40, Tomasz Chmielewski wrote:
> Gerd Hoffmann wrote:
>
[...]
> And what should I answer if I both use kqemu on some (old) hardware, 
> and kvm otherwise?
>

Checkboxes?

Rgds,
Anton

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Gerd Hoffmann]

On 06/05/09 10:40, Tomasz Chmielewski wrote:
> Gerd Hoffmann wrote:
>> On 06/05/09 02:44, Johannes Schindelin wrote:
>>> Hi,
>>>
>>> On Thu, 4 Jun 2009, Anton D Kachalov wrote:
>>>
>>>> There is one point missed: "I do not use kqemu". Just to have
>>>> statistics
>>>> weight for the other side.
>>>
>>> I think that is totally beside the point. The question is if it is worth
>>> to continue to support kqemu. And frankly, for that I could not care
>>> less
>>> if there are people _not_ using kqemu if there are enough that _do_ use
>>> kqemu to merit a continuation.
>>
>> A poll for both users and non-users would make sense IMHO. It should
>> include reasons for both groups though, i.e. like this:
>>
>> I use kqemu because:
>> [ ] old hardware
>> [ ] *BSD host
>> ....
>>
>> I don't use kqemu because:
>> [ ] using kvm instead
>> [ ] using virtualbox instead
>> [ ] doesn't work stable for me
>> ...
>
> And what should I answer if I both use kqemu on some (old) hardware, and
> kvm otherwise?

Make it multiple choice then, so you can check both "old hardware" and 
"use kvm".  Likewise one could mark both "bsd" + "old hardware" or "use 
virtualbox" + "not stable".

Could be further refined by a field for the number of machines for each 
choice, but it starts to become silly then ;)

cheers
   Gerd

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Lennart Sorensen]

On Thu, Jun 04, 2009 at 08:55:05PM +0400, Anton D Kachalov wrote:
> Good day, Anthony.
>
> There is one point missed: "I do not use kqemu".
> Just to have statistics weight for the other side.

Yeah I don't either.  I actually thought kvm had replaced it effectively.

-- 
Len Sorensen

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Johannes Schindelin]

Hi,

On Fri, 5 Jun 2009, Lennart Sorensen wrote:

> On Thu, Jun 04, 2009 at 08:55:05PM +0400, Anton D Kachalov wrote:
> > Good day, Anthony.
> >
> > There is one point missed: "I do not use kqemu".
> > Just to have statistics weight for the other side.
> 
> Yeah I don't either.  I actually thought kvm had replaced it effectively.

You might have realized from the available answers that not everybody is 
lucky enough to be able to afford 2 week old hardware, and therefore not 
everybody is able to use kvm.

Thankyouverymuch,
Dscho

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Jamie Lokier]

Johannes Schindelin wrote:
> > Yeah I don't either.  I actually thought kvm had replaced it effectively.
> 
> You might have realized from the available answers that not everybody is 
> lucky enough to be able to afford 2 week old hardware, and therefore not 
> everybody is able to use kvm.

Plus kvm's not suitable for some guests.  I'm thinking old Windows
guests with 16-bit kernel code here.

It has come up before that kvm will eventually support 16-bit code
better, although I got the impression that it would never support full
16-bit virtualisation accurately, so e.g. Windows 95 will not run on
it, nor some other partially 16-bit OSes.  Possibly not even very old
versions of Linux, I'm not sure.

Don't ask me _why_ I want to run them. :-)

Just a data point that it's not just about the host hardware, and as
far as I know kqemu can accelerate them.

-- Jamie

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Avi Kivity]

Jamie Lokier wrote:
> Johannes Schindelin wrote:
>   
>>> Yeah I don't either.  I actually thought kvm had replaced it effectively.
>>>       
>> You might have realized from the available answers that not everybody is 
>> lucky enough to be able to afford 2 week old hardware, and therefore not 
>> everybody is able to use kvm.
>>     
>
> Plus kvm's not suitable for some guests.  I'm thinking old Windows
> guests with 16-bit kernel code here.
>   

kvm on amd will run these perfectly.

> It has come up before that kvm will eventually support 16-bit code
> better, although I got the impression that it would never support full
> 16-bit virtualisation accurately, so e.g. Windows 95 will not run on
> it, nor some other partially 16-bit OSes.  Possibly not even very old
> versions of Linux, I'm not sure.
>
> Don't ask me _why_ I want to run them. :-)
>
> Just a data point that it's not just about the host hardware, and as
> far as I know kqemu can accelerate them.
>   

It falls back to qemu for 16-bit code.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Jamie Lokier]

Avi Kivity wrote:
> Jamie Lokier wrote:
> >Johannes Schindelin wrote:
> >  
> >>>Yeah I don't either.  I actually thought kvm had replaced it effectively.
> >>>      
> >>You might have realized from the available answers that not everybody is 
> >>lucky enough to be able to afford 2 week old hardware, and therefore not 
> >>everybody is able to use kvm.
> >>    
> >
> >Plus kvm's not suitable for some guests.  I'm thinking old Windows
> >guests with 16-bit kernel code here.
> >  
> 
> kvm on amd will run these perfectly.

So the "Guest Support Status" prominently on the front page of
linux-kvm.org is wrong for current versions?  It specifically mentions
AMD hosts.

(I notice AMD KVM != Intel KVM hasn't factored into this discussion yet...)

Guest           KVM tested             Host CPU/bits    Result
----------------------------------------------------------------
Windows 98SE 	kvm-63                 Intel 32         Fails
Windows 98SE 	kvm-80, 2.6.27.7       AMD 64           no way
Windows 95 	kvm-44, 2.6.23-rc8     AMD 64, 32 	no way

> >It has come up before that kvm will eventually support 16-bit code
> >better, although I got the impression that it would never support full
> >16-bit virtualisation accurately, so e.g. Windows 95 will not run on
> >it, nor some other partially 16-bit OSes.  Possibly not even very old
> >versions of Linux, I'm not sure.
> >
> >Don't ask me _why_ I want to run them. :-)
> >
> >Just a data point that it's not just about the host hardware, and as
> >far as I know kqemu can accelerate them.
> >  
> 
> It falls back to qemu for 16-bit code.

I was under the impression it was planned to remove TCG support when
using KVM.  If not, fine, it's ok for 16-bit code to run in TCG and
probably better than vm86 or the in-kernel interpreter.

-- Jamie

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Avi Kivity]

Jamie Lokier wrote:
>>> Plus kvm's not suitable for some guests.  I'm thinking old Windows
>>> guests with 16-bit kernel code here.
>>>  
>>>       
>> kvm on amd will run these perfectly.
>>     
>
> So the "Guest Support Status" prominently on the front page of
> linux-kvm.org is wrong for current versions?  It specifically mentions
> AMD hosts.
>
> (I notice AMD KVM != Intel KVM hasn't factored into this discussion yet...)
>
> Guest           KVM tested             Host CPU/bits    Result
> ----------------------------------------------------------------
> Windows 98SE 	kvm-63                 Intel 32         Fails
> Windows 98SE 	kvm-80, 2.6.27.7       AMD 64           no way
> Windows 95 	kvm-44, 2.6.23-rc8     AMD 64, 32 	no way
>   

Well, maybe there's some other bug in there.  But kvm-amd 16 bit support 
is as good as the native cpu's.  kvm-intel with the new 'unrestricted 
guest' should be the same.

>>> It has come up before that kvm will eventually support 16-bit code
>>> better, although I got the impression that it would never support full
>>> 16-bit virtualisation accurately, so e.g. Windows 95 will not run on
>>> it, nor some other partially 16-bit OSes.  Possibly not even very old
>>> versions of Linux, I'm not sure.
>>>
>>> Don't ask me _why_ I want to run them. :-)
>>>
>>> Just a data point that it's not just about the host hardware, and as
>>> far as I know kqemu can accelerate them.
>>>  
>>>       
>> It falls back to qemu for 16-bit code.
>>     
>
> I was under the impression it was planned to remove TCG support when
> using KVM.  If not, fine, it's ok for 16-bit code to run in TCG and
> probably better than vm86 or the in-kernel interpreter.
>   

vm86 doesn't work on x86_64.  kvm will run most 16-bit code natively, 
just have to complete task switch support and fix any bugs.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Jamie Lokier]

Avi Kivity wrote:
> Jamie Lokier wrote:
> >So the "Guest Support Status" prominently on the front page of
> >linux-kvm.org is wrong for current versions?  It specifically mentions
> >AMD hosts.
> >
> >(I notice AMD KVM != Intel KVM hasn't factored into this discussion yet...)
> >
> >Guest           KVM tested             Host CPU/bits    Result
> >----------------------------------------------------------------
> >Windows 98SE 	kvm-63                 Intel 32         Fails
> >Windows 98SE 	kvm-80, 2.6.27.7       AMD 64           no way
> >Windows 95 	kvm-44, 2.6.23-rc8     AMD 64, 32 	no way
> >  
> 
> Well, maybe there's some other bug in there.  But kvm-amd 16 bit support 
> is as good as the native cpu's.  kvm-intel with the new 'unrestricted 
> guest' should be the same.

I'm happy to test older guests on latest KVMs, and QEMU upstream with
KVM support if that works.

But the AMD and VIA hardware I have does not support KVM; all my
KVM-capable machines are Intels.

I could test using the nested-SVM support, I suppose, but I'm not that
masochistic yet. :-)  (I wonder if nested-SVM supports 16 bit nested guests).

Can you say a bit more about what 'unrestricted guest' means?  Does it
mean that some protection is disabled (like in vm86 mode on x86_32)?

> >>>It has come up before that kvm will eventually support 16-bit code
> >>>better, although I got the impression that it would never support full
> >>>16-bit virtualisation accurately, so e.g. Windows 95 will not run on
> >>>it, nor some other partially 16-bit OSes.  Possibly not even very old
> >>>versions of Linux, I'm not sure.
> >>>
> >>>Don't ask me _why_ I want to run them. :-)
> >>>
> >>>Just a data point that it's not just about the host hardware, and as
> >>>far as I know kqemu can accelerate them.
> >>> 
> >>>      
> >>It falls back to qemu for 16-bit code.
> >>    
> >
> >I was under the impression it was planned to remove TCG support when
> >using KVM.  If not, fine, it's ok for 16-bit code to run in TCG and
> >probably better than vm86 or the in-kernel interpreter.
> 
> vm86 doesn't work on x86_64.

I don't have any personal x86_64 machines, and nearly all my KVM usage
is done on x86_32 so it didn't cross my mind.

> kvm will run most 16-bit code natively, 
> just have to complete task switch support and fix any bugs.

Ah, the old "fix any bugs" caveat, combined with "most" :-)

I looked at KVM's 16-bit interpreter a few months ago, and it wasn't
clear (to me) if it covered the complete 16-bit opcode space.

Is there a reason to duplicate QEMU's task switch emulation, instead
of trapping out to QEMU?  Modern OSes don't use x86 task switching
(because it's slow on real CPUs) except for ring stack switches, so
it's hardly a performance requirement.  Accurate task switch support
is fiddly to get right.  Think of all the exceptions including
paging/segment exceptions in the middle of reading the TSS block.

-- Jamie

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Avi Kivity]

Jamie Lokier wrote:
> I'm happy to test older guests on latest KVMs, and QEMU upstream with
> KVM support if that works.
>
> But the AMD and VIA hardware I have does not support KVM; all my
> KVM-capable machines are Intels.
>
> I could test using the nested-SVM support, I suppose, but I'm not that
> masochistic yet. :-)  (I wonder if nested-SVM supports 16 bit nested guests).
>   

I think you mean tcg-svm, not nested svm.  If the guest's guest boots, 
then 16 bit mode works.

Of course, this area is heavily experimental.

> Can you say a bit more about what 'unrestricted guest' means?  Does it
> mean that some protection is disabled (like in vm86 mode on x86_32)?
>   

It's Intel-speak for "we fixed the bug where you couldn't virtualize 
real mode".

>> kvm will run most 16-bit code natively, 
>> just have to complete task switch support and fix any bugs.
>>     
>
> Ah, the old "fix any bugs" caveat, combined with "most" :-)
>
> I looked at KVM's 16-bit interpreter a few months ago, and it wasn't
> clear (to me) if it covered the complete 16-bit opcode space.
>   

It isn't complete, and things like interrupt injection aren't 
implemented at all.

> Is there a reason to duplicate QEMU's task switch emulation, instead
> of trapping out to QEMU?  Modern OSes don't use x86 task switching
> (because it's slow on real CPUs) except for ring stack switches, so
> it's hardly a performance requirement.  Accurate task switch support
> is fiddly to get right.  Think of all the exceptions including
> paging/segment exceptions in the middle of reading the TSS block.
>   

kvm is designed to be useful without full emulation in userspace.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

Avi Kivity wrote:
> Jamie Lokier wrote:
>> Is there a reason to duplicate QEMU's task switch emulation, instead
>> of trapping out to QEMU?  Modern OSes don't use x86 task switching
>> (because it's slow on real CPUs) except for ring stack switches, so
>> it's hardly a performance requirement.  Accurate task switch support
>> is fiddly to get right.  Think of all the exceptions including
>> paging/segment exceptions in the middle of reading the TSS block.
>>   
> 
> kvm is designed to be useful without full emulation in userspace.
> 

And the fact that kqemu has to use tcg in order to achieve a reasonable
performance is rather a disadvantage. The complexity and overhead for
synchronizing tcg with the in-kernel accelerator is enormous. If there
were a feasible way to overcome this with kqemu, it would benefit a lot.
But unfortunately there is none (given you don't want to invest
reasonable efforts).

Jan

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

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Jan Kiszka wrote:
> And the fact that kqemu has to use tcg in order to achieve a reasonable
> performance is rather a disadvantage. The complexity and overhead for
> synchronizing tcg with the in-kernel accelerator is enormous. If there
> were a feasible way to overcome this with kqemu, it would benefit a lot.
> But unfortunately there is none (given you don't want to invest
> reasonable efforts).
>   

Note that kvm suffers from something similar (to a smaller magnitude) as 
well: if a guest pages in its page tables, kvm knows nothing about it 
and will thus have outdated shadows.  To date we haven't encountered a 
problem with it, but it's conceivable.  I think Windows can page its 
page tables, but maybe it's disabled by default, or maybe it doesn't dma 
directly into the page tables.

Not sure how to fix.  Maybe write protect the host page tables when we 
shadow a page table, and get an mmu notifier to tell us when its made 
writable?  Seems expensive.  Burying head in sand is much easier.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

Avi Kivity wrote:
> Jan Kiszka wrote:
>> And the fact that kqemu has to use tcg in order to achieve a reasonable
>> performance is rather a disadvantage. The complexity and overhead for
>> synchronizing tcg with the in-kernel accelerator is enormous. If there
>> were a feasible way to overcome this with kqemu, it would benefit a lot.
>> But unfortunately there is none (given you don't want to invest
>> reasonable efforts).
>>   
> 
> Note that kvm suffers from something similar (to a smaller magnitude) as
> well: if a guest pages in its page tables, kvm knows nothing about it
> and will thus have outdated shadows.  To date we haven't encountered a
> problem with it, but it's conceivable.  I think Windows can page its
> page tables, but maybe it's disabled by default, or maybe it doesn't dma
> directly into the page tables.

Can't follow, always thought that kernel space gets informed when some
I/O operation handled by user space modified an "interesting" page.

> 
> Not sure how to fix.  Maybe write protect the host page tables when we

You mean guest page table?

> shadow a page table, and get an mmu notifier to tell us when its made
> writable?  Seems expensive.  Burying head in sand is much easier.
> 

Does this still apply to nested paging? I guess (hope) not...

Jan

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

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>> Jan Kiszka wrote:
>>     
>>> And the fact that kqemu has to use tcg in order to achieve a reasonable
>>> performance is rather a disadvantage. The complexity and overhead for
>>> synchronizing tcg with the in-kernel accelerator is enormous. If there
>>> were a feasible way to overcome this with kqemu, it would benefit a lot.
>>> But unfortunately there is none (given you don't want to invest
>>> reasonable efforts).
>>>   
>>>       
>> Note that kvm suffers from something similar (to a smaller magnitude) as
>> well: if a guest pages in its page tables, kvm knows nothing about it
>> and will thus have outdated shadows.  To date we haven't encountered a
>> problem with it, but it's conceivable.  I think Windows can page its
>> page tables, but maybe it's disabled by default, or maybe it doesn't dma
>> directly into the page tables.
>>     
>
> Can't follow, always thought that kernel space gets informed when some
> I/O operation handled by user space modified an "interesting" page.
>   

It doesn't.  Host userspace has unrestricted access to guest memory.

>> Not sure how to fix.  Maybe write protect the host page tables when we
>>     
>
> You mean guest page table?
>   

Both :)

When kvm write protects a guest page table in the shadow page table 
entries pointing to that guest page, it should also write protect the 
guest page table in the host page table entries to the same guest page.

>> shadow a page table, and get an mmu notifier to tell us when its made
>> writable?  Seems expensive.  Burying head in sand is much easier.
>>
>>     
>
> Does this still apply to nested paging? I guess (hope) not...
>   

No, nested paging brings cancer and cures world peace.  Or something.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

Avi Kivity wrote:
> Jan Kiszka wrote:
>> Avi Kivity wrote:
>>  
>>> Jan Kiszka wrote:
>>>    
>>>> And the fact that kqemu has to use tcg in order to achieve a reasonable
>>>> performance is rather a disadvantage. The complexity and overhead for
>>>> synchronizing tcg with the in-kernel accelerator is enormous. If there
>>>> were a feasible way to overcome this with kqemu, it would benefit a
>>>> lot.
>>>> But unfortunately there is none (given you don't want to invest
>>>> reasonable efforts).
>>>>         
>>> Note that kvm suffers from something similar (to a smaller magnitude) as
>>> well: if a guest pages in its page tables, kvm knows nothing about it
>>> and will thus have outdated shadows.  To date we haven't encountered a
>>> problem with it, but it's conceivable.  I think Windows can page its
>>> page tables, but maybe it's disabled by default, or maybe it doesn't dma
>>> directly into the page tables.
>>>     
>>
>> Can't follow, always thought that kernel space gets informed when some
>> I/O operation handled by user space modified an "interesting" page.
>>   
> 
> It doesn't.  Host userspace has unrestricted access to guest memory.
> 
>>> Not sure how to fix.  Maybe write protect the host page tables when we
>>>     
>>
>> You mean guest page table?
>>   
> 
> Both :)
> 
> When kvm write protects a guest page table in the shadow page table
> entries pointing to that guest page, it should also write protect the
> guest page table in the host page table entries to the same guest page.

Ah, now I got it. What do other hypervisors do?

> 
>>> shadow a page table, and get an mmu notifier to tell us when its made
>>> writable?  Seems expensive.  Burying head in sand is much easier.
>>>
>>>     
>>
>> Does this still apply to nested paging? I guess (hope) not...
>>   
> 
> No, nested paging brings cancer and cures world peace.  Or something.
> 

Well, then it's probably not worth bothering, at least until a real
guest problem is explainable with this limitation. Are there any
suspicious reports floating around (maybe not only about Windows)?

Jan

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

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Jan Kiszka wrote:
>> When kvm write protects a guest page table in the shadow page table
>> entries pointing to that guest page, it should also write protect the
>> guest page table in the host page table entries to the same guest page.
>>     
>
> Ah, now I got it. What do other hypervisors do?
>   

As far as I can tell, Xen's head is in the sand too.  No idea about 
others.  I think qemu/tcg is fine.

>>> Does this still apply to nested paging? I guess (hope) not...
>>>   
>>>       
>> No, nested paging brings cancer and cures world peace.  Or something.
>>
>>     
>
> Well, then it's probably not worth bothering, at least until a real
> guest problem is explainable with this limitation. 

I agree.

> Are there any
> suspicious reports floating around (maybe not only about Windows)?
>   

Not that I'm aware of.  Paging page tables is tricky business.  Given 
that the pointed-to pages may have been evicted while the page table was 
in swap, I guess a guest would have to revalidate the entries anyway, 
thus triggering re-shadowing.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

Avi Kivity wrote:
> Jamie Lokier wrote:
>>>> Plus kvm's not suitable for some guests.  I'm thinking old Windows
>>>> guests with 16-bit kernel code here.
>>>>  
>>>>       
>>> kvm on amd will run these perfectly.
>>>     
>>
>> So the "Guest Support Status" prominently on the front page of
>> linux-kvm.org is wrong for current versions?  It specifically mentions
>> AMD hosts.
>>
>> (I notice AMD KVM != Intel KVM hasn't factored into this discussion
>> yet...)
>>
>> Guest           KVM tested             Host CPU/bits    Result
>> ----------------------------------------------------------------
>> Windows 98SE     kvm-63                 Intel 32         Fails
>> Windows 98SE     kvm-80, 2.6.27.7       AMD 64           no way
>> Windows 95     kvm-44, 2.6.23-rc8     AMD 64, 32     no way
>>   
> 
> Well, maybe there's some other bug in there.  But kvm-amd 16 bit support
> is as good as the native cpu's.  kvm-intel with the new 'unrestricted
> guest' should be the same.

That's about 16-bit real mode.

FWIW, we are running a 16-bit heavily segmented protected mode OS inside
kvm for quite a while now. Works smoothly on both amd and intel.

> 
>>>> It has come up before that kvm will eventually support 16-bit code
>>>> better, although I got the impression that it would never support full
>>>> 16-bit virtualisation accurately, so e.g. Windows 95 will not run on
>>>> it, nor some other partially 16-bit OSes.  Possibly not even very old
>>>> versions of Linux, I'm not sure.
>>>>
>>>> Don't ask me _why_ I want to run them. :-)
>>>>
>>>> Just a data point that it's not just about the host hardware, and as
>>>> far as I know kqemu can accelerate them.
>>>>  
>>>>       
>>> It falls back to qemu for 16-bit code.
>>>     
>>
>> I was under the impression it was planned to remove TCG support when
>> using KVM.  If not, fine, it's ok for 16-bit code to run in TCG and
>> probably better than vm86 or the in-kernel interpreter.
>>   
> 
> vm86 doesn't work on x86_64.  kvm will run most 16-bit code natively,
> just have to complete task switch support and fix any bugs.
> 

Regarding kqemu: It runs real-mode code in tcg, which is probably faster
than in-kernel interpretation, but definitely slower than the native
execution you get with amd and soon also intel.

When it comes to 16-bit protected mode, kqemu attempts to run it in the
accelerator. But, as reported earlier, it quickly falls into pieces once
the guest tries to make serious use of x86 protected mode. We tried to
improve this, but it turned out to be a dead end, not only because of
kqemu itself but also because of the inherent issues legacy x86 hardware
has /wrt virtualization. So nothing to score for kqemu here, too.

Jan

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

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Lennart Sorensen]

On Sat, Jun 06, 2009 at 01:23:37AM +0200, Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 5 Jun 2009, Lennart Sorensen wrote:
> 
> > On Thu, Jun 04, 2009 at 08:55:05PM +0400, Anton D Kachalov wrote:
> > > Good day, Anthony.
> > >
> > > There is one point missed: "I do not use kqemu".
> > > Just to have statistics weight for the other side.
> > 
> > Yeah I don't either.  I actually thought kvm had replaced it effectively.
> 
> You might have realized from the available answers that not everybody is 
> lucky enough to be able to afford 2 week old hardware, and therefore not 
> everybody is able to use kvm.

Well I can't run kvm on most of my hardware.  Strangely I thought
(apparently incorrectly) that kqemu needed hardware virtualization
support too.  I mainly use qemu to emulate powerpc so kqemu and kvm has
been more just a toy to play around with, although I am starting to use
kvm a bit now for other things.  Seems nicer than vmware actually,
as long as you have hardware that can run it.

-- 
Len Sorensen

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Andreas Färber]

Am 03.06.2009 um 23:57 schrieb Anthony Liguori:

> I'm curious to know who all out there is using kqemu and why they are
> using it.  Please take a moment to fill out the following poll if you
> use kqemu.  Having actual data as to why people are using kqemu may  
> help
> figure out the best way to replace it in the future.
>
> http://www.micropoll.com/akira/mpview/604126-172373

Thanks for this move. Some flaws have already been pointed out - the  
above poll doesn't allow multiple choices and focuses on the why from  
a platform/hardware viewpoint.

Since you are looking for comments from users, did you post this on  
users' lists or forums as well?

While polls never get feedback from everybody, one group you are  
unlikely to reach this way is those users that don't care what kernel  
modules may be installed for them, as long as they work, on machines  
they don't have priviledges on. They'll simply notice the performance  
difference once it's gone. And I doubt all the admins will be reading  
the development lists of the hundreds of packages coming with the full  
installation on their systems.

Or as another example, I've been unable to try KVM with svn/git QEMU  
because new capability defines keep being added that block compiling  
QEMU with KVM from any mainstream distribution. With nobody here being  
able to recommend a working distribution, that makes KVM a moot  
alternative, especially on systems you can't install your own kernel  
modules on. I just hope that Fedora 11 will let me try it.

Andreas

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Avi Kivity]

Andreas Färber wrote:
> Or as another example, I've been unable to try KVM with svn/git QEMU 
> because new capability defines keep being added that block compiling 
> QEMU with KVM from any mainstream distribution. With nobody here being 
> able to recommend a working distribution, that makes KVM a moot 
> alternative, especially on systems you can't install your own kernel 
> modules on. I just hope that Fedora 11 will let me try it.

Try qemu-kvm.git, that should compile and run on almost anything (and is 
a lot faster and more featureful than kvm support in qemu.git).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] POLL: Why do you use kqemu?

[Blue Swirl]

On 6/6/09, Avi Kivity <avi@redhat.com> wrote:
> Andreas Färber wrote:
>
> > Or as another example, I've been unable to try KVM with svn/git QEMU
> because new capability defines keep being added that block compiling QEMU
> with KVM from any mainstream distribution. With nobody here being able to
> recommend a working distribution, that makes KVM a moot alternative,
> especially on systems you can't install your own kernel modules on. I just
> hope that Fedora 11 will let me try it.
> >
>
>  Try qemu-kvm.git, that should compile and run on almost anything (and is a
> lot faster and more featureful than kvm support in qemu.git).

Maybe the backwards compatibility features should be ported to QEMU?
For example, is there a workaround for
#error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
?

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

Blue Swirl wrote:
> On 6/6/09, Avi Kivity <avi@redhat.com> wrote:
>> Andreas Färber wrote:
>>
>>> Or as another example, I've been unable to try KVM with svn/git QEMU
>> because new capability defines keep being added that block compiling QEMU
>> with KVM from any mainstream distribution. With nobody here being able to
>> recommend a working distribution, that makes KVM a moot alternative,
>> especially on systems you can't install your own kernel modules on. I just
>> hope that Fedora 11 will let me try it.
>>  Try qemu-kvm.git, that should compile and run on almost anything (and is a
>> lot faster and more featureful than kvm support in qemu.git).
> 
> Maybe the backwards compatibility features should be ported to QEMU?
> For example, is there a workaround for
> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
> ?

Given that we have always-up-to-date kvm-kmod packages with support down
to reasonable kernel versions, I would prefer to keep upstream clean
from old workarounds. They should only be needed for issues found very
recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
the future.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Blue Swirl]

On 6/6/09, Jan Kiszka <jan.kiszka@web.de> wrote:
> Blue Swirl wrote:
>  > On 6/6/09, Avi Kivity <avi@redhat.com> wrote:
>  >> Andreas Färber wrote:
>  >>
>  >>> Or as another example, I've been unable to try KVM with svn/git QEMU
>  >> because new capability defines keep being added that block compiling QEMU
>  >> with KVM from any mainstream distribution. With nobody here being able to
>  >> recommend a working distribution, that makes KVM a moot alternative,
>  >> especially on systems you can't install your own kernel modules on. I just
>  >> hope that Fedora 11 will let me try it.
>  >>  Try qemu-kvm.git, that should compile and run on almost anything (and is a
>  >> lot faster and more featureful than kvm support in qemu.git).
>  >
>  > Maybe the backwards compatibility features should be ported to QEMU?
>  > For example, is there a workaround for
>  > #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>  > ?
>
>
> Given that we have always-up-to-date kvm-kmod packages with support down
>  to reasonable kernel versions, I would prefer to keep upstream clean
>  from old workarounds. They should only be needed for issues found very
>  recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>  the future.

But then I (and from Andreas' message I gather that many others) can't
test KVM support on QEMU without building, installing and maintaining
(updating, rebuilding, reinstalling etc) my own kernel instead of the
distro build.

Does this also mean that KVM stuff in QEMU releases will not be usable
for anyone (except those building their own kernels) until distros
upgrade to a compatible kernel version a few years later?

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

Blue Swirl wrote:
> On 6/6/09, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Blue Swirl wrote:
>>  > On 6/6/09, Avi Kivity <avi@redhat.com> wrote:
>>  >> Andreas Färber wrote:
>>  >>
>>  >>> Or as another example, I've been unable to try KVM with svn/git QEMU
>>  >> because new capability defines keep being added that block compiling QEMU
>>  >> with KVM from any mainstream distribution. With nobody here being able to
>>  >> recommend a working distribution, that makes KVM a moot alternative,
>>  >> especially on systems you can't install your own kernel modules on. I just
>>  >> hope that Fedora 11 will let me try it.
>>  >>  Try qemu-kvm.git, that should compile and run on almost anything (and is a
>>  >> lot faster and more featureful than kvm support in qemu.git).
>>  >
>>  > Maybe the backwards compatibility features should be ported to QEMU?
>>  > For example, is there a workaround for
>>  > #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>>  > ?
>>
>>
>> Given that we have always-up-to-date kvm-kmod packages with support down
>>  to reasonable kernel versions, I would prefer to keep upstream clean
>>  from old workarounds. They should only be needed for issues found very
>>  recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>>  the future.
> 
> But then I (and from Andreas' message I gather that many others) can't
> test KVM support on QEMU without building, installing and maintaining
> (updating, rebuilding, reinstalling etc) my own kernel instead of the
> distro build.

You don't have to, it builds against the distro kernel's devel package
(I'm doing most KVM development on boring distro kernels). No black
magic involved. Really.

> 
> Does this also mean that KVM stuff in QEMU releases will not be usable
> for anyone (except those building their own kernels) until distros
> upgrade to a compatible kernel version a few years later?

In a year from now, you won't need any of todays workarounds on a then
up-to-date distro kernel. And given that not only bug fixes come with
kvm-kmod but also feature enhancements, updating the in-kernel kvm
modules that way will likely remain a valid use case even after that point.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Andreas Färber]

Am 06.06.2009 um 19:32 schrieb Jan Kiszka:

> Blue Swirl wrote:
>> On 6/6/09, Jan Kiszka <jan.kiszka@web.de> wrote:
>>> Blue Swirl wrote:
>>>> Maybe the backwards compatibility features should be ported to  
>>>> QEMU?
>>>> For example, is there a workaround for
>>>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>>>> ?
>>>
>>> Given that we have always-up-to-date kvm-kmod packages with  
>>> support down
>>> to reasonable kernel versions, I would prefer to keep upstream clean
>>> from old workarounds. They should only be needed for issues found  
>>> very
>>> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be  
>>> found in
>>> the future.
>>
>> But then I (and from Andreas' message I gather that many others)  
>> can't
>> test KVM support on QEMU without building, installing and maintaining
>> (updating, rebuilding, reinstalling etc) my own kernel instead of the
>> distro build.
>
> You don't have to, it builds against the distro kernel's devel package
> (I'm doing most KVM development on boring distro kernels). No black
> magic involved. Really.

Consider me Joe User in that aspect: I have a fairly recent amd64  
Linux machine, with all the latest security, bugfix and enhancement  
updates installed.

$ uname -a
Linux redhead 2.6.27.24-170.2.68.fc10.x86_64 #1 SMP Wed May 20  
22:47:23 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
$ ./configure
[...]
#error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS

A package search for kvm results in kvm-74-10.fc10 being installed  
(plus another one with ROMs). There is no additional kvm-kmod package  
offered that I could install. What should I do?

I could try qemu-kvm.git, yes, but for one thing Anthony has been  
insistant that patches be made against upstream qemu.git and for  
another it makes me dependent on someone merging KVM-unrelated commits  
(like sparc) into qemu-kvm.git, so it doesn't sound like a longterm  
solution.

This is not about me, it's about the average user that might or might  
not use kqemu and wants to use KVM on Linux. qemu.git's configure just  
blocks them. Not just now, where Fedora 11 is four days away, it's  
been similar on Fedora 9 and throughout Fedora 10, as indicated earlier.

There are at least two solutions:

i) Make configure hint users what to do. (README just references qemu- 
doc.html, which is not yet built and doesn't contain anything helpful  
here anyway.) Other options are even less verbose though (e.g.  
Documentation). Building a new kernel or kernel module is not always  
an option.

ii) Merge the apparently existant workarounds upstream. I thought this  
was the overall plan anyway? Has this changed, like the original plan  
of Glauber's kqemu-friendly qemu-accel abstraction?

Sourceforge (the KVM download link) appears to be down currently btw.  
Savannah is not the only one with problems, it seems.

Andreas

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Andreas Färber wrote:
>>
>> You don't have to, it builds against the distro kernel's devel package
>> (I'm doing most KVM development on boring distro kernels). No black
>> magic involved. Really.
>
> Consider me Joe User in that aspect: I have a fairly recent amd64 
> Linux machine, with all the latest security, bugfix and enhancement 
> updates installed.

Joe would just use the packaged qemu from his distro.  That happens to 
be built from qemu-kvm.git, so Joe is already way ahead of you.

>
> $ uname -a
> Linux redhead 2.6.27.24-170.2.68.fc10.x86_64 #1 SMP Wed May 20 
> 22:47:23 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
> $ ./configure
> [...]
> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS

Like I said, try qemu-kvm.git.

>
> A package search for kvm results in kvm-74-10.fc10 being installed 
> (plus another one with ROMs). There is no additional kvm-kmod package 
> offered that I could install. What should I do?
>
> I could try qemu-kvm.git, yes, but for one thing Anthony has been 
> insistant that patches be made against upstream qemu.git and for 
> another it makes me dependent on someone merging KVM-unrelated commits 
> (like sparc) into qemu-kvm.git, so it doesn't sound like a longterm 
> solution.

I also insist on it.  Try 'git log' on qemu-kvm.git to see why.

>
> There are at least two solutions:
>
> i) Make configure hint users what to do. (README just references 
> qemu-doc.html, which is not yet built and doesn't contain anything 
> helpful here anyway.) Other options are even less verbose though (e.g. 
> Documentation). Building a new kernel or kernel module is not always 
> an option.

Agree.

>
> ii) Merge the apparently existant workarounds upstream. I thought this 
> was the overall plan anyway? Has this changed, like the original plan 
> of Glauber's kqemu-friendly qemu-accel abstraction?

It hasn't changed, it's just moving at a snail's pace.

> Sourceforge (the KVM download link) appears to be down currently btw. 
> Savannah is not the only one with problems, it seems.

Seems to be up now.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Jan Kiszka wrote:
>> Maybe the backwards compatibility features should be ported to QEMU?
>> For example, is there a workaround for
>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>> ?
>>     
>
> Given that we have always-up-to-date kvm-kmod packages with support down
> to reasonable kernel versions, I would prefer to keep upstream clean
> from old workarounds. They should only be needed for issues found very
> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
> the future.
>   

Requiring the latest up-to-date modules is pushing the problem to the 
users.  Sometimes there is no choice, but when there is, the 
implementation that cares about its uses prefer unclean code and 
functionality over perfection and brokenness.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

Avi Kivity wrote:
> Jan Kiszka wrote:
>>> Maybe the backwards compatibility features should be ported to QEMU?
>>> For example, is there a workaround for
>>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>>> ?
>>>     
>>
>> Given that we have always-up-to-date kvm-kmod packages with support down
>> to reasonable kernel versions, I would prefer to keep upstream clean
>> from old workarounds. They should only be needed for issues found very
>> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>> the future.
>>   
> 
> Requiring the latest up-to-date modules is pushing the problem to the
> users.  Sometimes there is no choice, but when there is, the
> implementation that cares about its uses prefer unclean code and
> functionality over perfection and brokenness.

Let's make it more concrete:

By the time upstream is as well tested, feature-rich and with comparable
performance as qemu-kvm, its current baseline requirement (2.6.29 due to
KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most
normal users. Until then they are better off with qemu-kvm anyway.

So all I wanted to express is that I see no point in merging workarounds
upstream that hardly anyone will need but that restrict non-kvm code in
upstream. Basically I have the current line along
KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in
mind. Anything older should be skipped when merging upstream. And unless
something more problematic comes along (rather unlikely), 2.6.29 or
compatible kvm-kmod is a reasonable minimum requirement for the long term.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>> Jan Kiszka wrote:
>>     
>>>> Maybe the backwards compatibility features should be ported to QEMU?
>>>> For example, is there a workaround for
>>>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>>>> ?
>>>>     
>>>>         
>>> Given that we have always-up-to-date kvm-kmod packages with support down
>>> to reasonable kernel versions, I would prefer to keep upstream clean
>>> from old workarounds. They should only be needed for issues found very
>>> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>>> the future.
>>>   
>>>       
>> Requiring the latest up-to-date modules is pushing the problem to the
>> users.  Sometimes there is no choice, but when there is, the
>> implementation that cares about its uses prefer unclean code and
>> functionality over perfection and brokenness.
>>     
>
> Let's make it more concrete:
>
> By the time upstream is as well tested, feature-rich and with comparable
> performance as qemu-kvm, its current baseline requirement (2.6.29 due to
> KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most
> normal users. Until then they are better off with qemu-kvm anyway.
>
> So all I wanted to express is that I see no point in merging workarounds
> upstream that hardly anyone will need but that restrict non-kvm code in
> upstream. Basically I have the current line along
> KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in
> mind. Anything older should be skipped when merging upstream. And unless
> something more problematic comes along (rather unlikely), 2.6.29 or
> compatible kvm-kmod is a reasonable minimum requirement for the long term.
>   

If you put it that way, I agree.  It's reasonable for qemu.git to target 
2.6.29.latest, unless it starts gaining features very rapidly.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Blue Swirl]

On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
> Avi Kivity wrote:
>  > Jan Kiszka wrote:
>  >>> Maybe the backwards compatibility features should be ported to QEMU?
>  >>> For example, is there a workaround for
>  >>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>  >>> ?
>  >>>
>  >>
>  >> Given that we have always-up-to-date kvm-kmod packages with support down
>  >> to reasonable kernel versions, I would prefer to keep upstream clean
>  >> from old workarounds. They should only be needed for issues found very
>  >> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>  >> the future.
>  >>
>  >
>  > Requiring the latest up-to-date modules is pushing the problem to the
>  > users.  Sometimes there is no choice, but when there is, the
>  > implementation that cares about its uses prefer unclean code and
>  > functionality over perfection and brokenness.
>
>
> Let's make it more concrete:
>
>  By the time upstream is as well tested, feature-rich and with comparable
>  performance as qemu-kvm, its current baseline requirement (2.6.29 due to
>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most
>  normal users. Until then they are better off with qemu-kvm anyway.
>
>  So all I wanted to express is that I see no point in merging workarounds
>  upstream that hardly anyone will need but that restrict non-kvm code in
>  upstream. Basically I have the current line along
>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in
>  mind. Anything older should be skipped when merging upstream. And unless
>  something more problematic comes along (rather unlikely), 2.6.29 or
>  compatible kvm-kmod is a reasonable minimum requirement for the long term.

I pulled qemu-kvm and it looks to me that
KVM_CAP_DESTROY_MEMORY_REGION_WORKS and the derived functions
kvm_destroy_memory_region_works() and must_use_aliases_*() are only
used in very few places. Do I miss something, how can this be of any
restriction?

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

Blue Swirl wrote:
> On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Avi Kivity wrote:
>>  > Jan Kiszka wrote:
>>  >>> Maybe the backwards compatibility features should be ported to QEMU?
>>  >>> For example, is there a workaround for
>>  >>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>>  >>> ?
>>  >>>
>>  >>
>>  >> Given that we have always-up-to-date kvm-kmod packages with support down
>>  >> to reasonable kernel versions, I would prefer to keep upstream clean
>>  >> from old workarounds. They should only be needed for issues found very
>>  >> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>>  >> the future.
>>  >>
>>  >
>>  > Requiring the latest up-to-date modules is pushing the problem to the
>>  > users.  Sometimes there is no choice, but when there is, the
>>  > implementation that cares about its uses prefer unclean code and
>>  > functionality over perfection and brokenness.
>>
>>
>> Let's make it more concrete:
>>
>>  By the time upstream is as well tested, feature-rich and with comparable
>>  performance as qemu-kvm, its current baseline requirement (2.6.29 due to
>>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most
>>  normal users. Until then they are better off with qemu-kvm anyway.
>>
>>  So all I wanted to express is that I see no point in merging workarounds
>>  upstream that hardly anyone will need but that restrict non-kvm code in
>>  upstream. Basically I have the current line along
>>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in
>>  mind. Anything older should be skipped when merging upstream. And unless
>>  something more problematic comes along (rather unlikely), 2.6.29 or
>>  compatible kvm-kmod is a reasonable minimum requirement for the long term.
> 
> I pulled qemu-kvm and it looks to me that
> KVM_CAP_DESTROY_MEMORY_REGION_WORKS and the derived functions
> kvm_destroy_memory_region_works() and must_use_aliases_*() are only
> used in very few places. Do I miss something, how can this be of any
> restriction?

Check e.g the diff of hw/vga.c against upstream: All the magic dances
there are required as qemu-kvm tracking cpu_register_physical_memory and
kvm_log_start cannot cope with all the patterns normal qemu code comes
up with. Upstream slot management now provides the same features
(including migration) like qemu-kvm, it just does not deal with legacy,
thus it does not have to patch qemu code (rather, we were able to remove
some already merged hooks - vga_dirty_log_stop).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Blue Swirl]

On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
> Blue Swirl wrote:
>  > On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
>  >> Avi Kivity wrote:
>  >>  > Jan Kiszka wrote:
>  >>  >>> Maybe the backwards compatibility features should be ported to QEMU?
>  >>  >>> For example, is there a workaround for
>  >>  >>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>  >>  >>> ?
>  >>  >>>
>  >>  >>
>  >>  >> Given that we have always-up-to-date kvm-kmod packages with support down
>  >>  >> to reasonable kernel versions, I would prefer to keep upstream clean
>  >>  >> from old workarounds. They should only be needed for issues found very
>  >>  >> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>  >>  >> the future.
>  >>  >>
>  >>  >
>  >>  > Requiring the latest up-to-date modules is pushing the problem to the
>  >>  > users.  Sometimes there is no choice, but when there is, the
>  >>  > implementation that cares about its uses prefer unclean code and
>  >>  > functionality over perfection and brokenness.
>  >>
>  >>
>  >> Let's make it more concrete:
>  >>
>  >>  By the time upstream is as well tested, feature-rich and with comparable
>  >>  performance as qemu-kvm, its current baseline requirement (2.6.29 due to
>  >>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most
>  >>  normal users. Until then they are better off with qemu-kvm anyway.
>  >>
>  >>  So all I wanted to express is that I see no point in merging workarounds
>  >>  upstream that hardly anyone will need but that restrict non-kvm code in
>  >>  upstream. Basically I have the current line along
>  >>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in
>  >>  mind. Anything older should be skipped when merging upstream. And unless
>  >>  something more problematic comes along (rather unlikely), 2.6.29 or
>  >>  compatible kvm-kmod is a reasonable minimum requirement for the long term.
>  >
>  > I pulled qemu-kvm and it looks to me that
>  > KVM_CAP_DESTROY_MEMORY_REGION_WORKS and the derived functions
>  > kvm_destroy_memory_region_works() and must_use_aliases_*() are only
>  > used in very few places. Do I miss something, how can this be of any
>  > restriction?
>
>
> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>  there are required as qemu-kvm tracking cpu_register_physical_memory and
>  kvm_log_start cannot cope with all the patterns normal qemu code comes
>  up with. Upstream slot management now provides the same features
>  (including migration) like qemu-kvm, it just does not deal with legacy,
>  thus it does not have to patch qemu code (rather, we were able to remove
>  some already merged hooks - vga_dirty_log_stop).

Still not very restrictive, all this could be encapsulated with for
example macro COMPAT_NO_DMRW which could be removed when we don't care
anymore. Next?

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3462 bytes --]

Blue Swirl wrote:
> On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Blue Swirl wrote:
>>  > On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
>>  >> Avi Kivity wrote:
>>  >>  > Jan Kiszka wrote:
>>  >>  >>> Maybe the backwards compatibility features should be ported to QEMU?
>>  >>  >>> For example, is there a workaround for
>>  >>  >>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>>  >>  >>> ?
>>  >>  >>>
>>  >>  >>
>>  >>  >> Given that we have always-up-to-date kvm-kmod packages with support down
>>  >>  >> to reasonable kernel versions, I would prefer to keep upstream clean
>>  >>  >> from old workarounds. They should only be needed for issues found very
>>  >>  >> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>>  >>  >> the future.
>>  >>  >>
>>  >>  >
>>  >>  > Requiring the latest up-to-date modules is pushing the problem to the
>>  >>  > users.  Sometimes there is no choice, but when there is, the
>>  >>  > implementation that cares about its uses prefer unclean code and
>>  >>  > functionality over perfection and brokenness.
>>  >>
>>  >>
>>  >> Let's make it more concrete:
>>  >>
>>  >>  By the time upstream is as well tested, feature-rich and with comparable
>>  >>  performance as qemu-kvm, its current baseline requirement (2.6.29 due to
>>  >>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most
>>  >>  normal users. Until then they are better off with qemu-kvm anyway.
>>  >>
>>  >>  So all I wanted to express is that I see no point in merging workarounds
>>  >>  upstream that hardly anyone will need but that restrict non-kvm code in
>>  >>  upstream. Basically I have the current line along
>>  >>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in
>>  >>  mind. Anything older should be skipped when merging upstream. And unless
>>  >>  something more problematic comes along (rather unlikely), 2.6.29 or
>>  >>  compatible kvm-kmod is a reasonable minimum requirement for the long term.
>>  >
>>  > I pulled qemu-kvm and it looks to me that
>>  > KVM_CAP_DESTROY_MEMORY_REGION_WORKS and the derived functions
>>  > kvm_destroy_memory_region_works() and must_use_aliases_*() are only
>>  > used in very few places. Do I miss something, how can this be of any
>>  > restriction?
>>
>>
>> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>>  there are required as qemu-kvm tracking cpu_register_physical_memory and
>>  kvm_log_start cannot cope with all the patterns normal qemu code comes
>>  up with. Upstream slot management now provides the same features
>>  (including migration) like qemu-kvm, it just does not deal with legacy,
>>  thus it does not have to patch qemu code (rather, we were able to remove
>>  some already merged hooks - vga_dirty_log_stop).
> 
> Still not very restrictive, all this could be encapsulated with for
> example macro COMPAT_NO_DMRW which could be removed when we don't care
> anymore. Next?

Really, it's not worth the maintenance pain: Every new device emulation
code that wants to be KVM-legacy-compatible would need to be written
like that. And unless you are familiar with the slot management
internals, the "correct" pattern will not be obvious.

I've just finished a patch for configure and for the runtime code to
tell the user what the maturer alternatives are. Will send it out in a
minute.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Jan Kiszka wrote:
>>>
>>> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>>>  there are required as qemu-kvm tracking cpu_register_physical_memory and
>>>  kvm_log_start cannot cope with all the patterns normal qemu code comes
>>>  up with. Upstream slot management now provides the same features
>>>  (including migration) like qemu-kvm, it just does not deal with legacy,
>>>  thus it does not have to patch qemu code (rather, we were able to remove
>>>  some already merged hooks - vga_dirty_log_stop).
>>>       
>> Still not very restrictive, all this could be encapsulated with for
>> example macro COMPAT_NO_DMRW which could be removed when we don't care
>> anymore. Next?
>>     
>
> Really, it's not worth the maintenance pain: Every new device emulation
> code that wants to be KVM-legacy-compatible would need to be written
> like that. And unless you are familiar with the slot management
> internals, the "correct" pattern will not be obvious.
>   

Only devices which direct map memory.  Currently VGA and cirrus.



-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

Avi Kivity wrote:
> Jan Kiszka wrote:
>>>>
>>>> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>>>>  there are required as qemu-kvm tracking
>>>> cpu_register_physical_memory and
>>>>  kvm_log_start cannot cope with all the patterns normal qemu code comes
>>>>  up with. Upstream slot management now provides the same features
>>>>  (including migration) like qemu-kvm, it just does not deal with
>>>> legacy,
>>>>  thus it does not have to patch qemu code (rather, we were able to
>>>> remove
>>>>  some already merged hooks - vga_dirty_log_stop).
>>>>       
>>> Still not very restrictive, all this could be encapsulated with for
>>> example macro COMPAT_NO_DMRW which could be removed when we don't care
>>> anymore. Next?
>>>     
>>
>> Really, it's not worth the maintenance pain: Every new device emulation
>> code that wants to be KVM-legacy-compatible would need to be written
>> like that. And unless you are familiar with the slot management
>> internals, the "correct" pattern will not be obvious.
>>   
> 
> Only devices which direct map memory.  Currently VGA and cirrus.
> 

--- /data/qemu/hw/piix_pci.c    2009-06-07 09:42:27.000000000 +0200
+++ hw/piix_pci.c       2009-06-02 13:00:09.000000000 +0200
...
@@ -91,6 +93,10 @@ static void i440fx_update_memory_mapping
     int i, r;
     uint32_t smram, addr;

+    if (kvm_enabled()) {
+        /* FIXME: Support remappings and protection changes. */
+        return;
+    }
     update_pam(d, 0xf0000, 0x100000, (d->config[0x59] >> 4) & 3);
     for(i = 0; i < 12; i++) {
         r = (d->config[(i >> 1) + 0x5a] >> ((i & 1) * 4)) & 3;

IIRC, this is at least partially due to the restricted slot management
in qemu-kvm - or is this obsolete now?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>> Jan Kiszka wrote:
>>     
>>>>> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>>>>>  there are required as qemu-kvm tracking
>>>>> cpu_register_physical_memory and
>>>>>  kvm_log_start cannot cope with all the patterns normal qemu code comes
>>>>>  up with. Upstream slot management now provides the same features
>>>>>  (including migration) like qemu-kvm, it just does not deal with
>>>>> legacy,
>>>>>  thus it does not have to patch qemu code (rather, we were able to
>>>>> remove
>>>>>  some already merged hooks - vga_dirty_log_stop).
>>>>>       
>>>>>           
>>>> Still not very restrictive, all this could be encapsulated with for
>>>> example macro COMPAT_NO_DMRW which could be removed when we don't care
>>>> anymore. Next?
>>>>     
>>>>         
>>> Really, it's not worth the maintenance pain: Every new device emulation
>>> code that wants to be KVM-legacy-compatible would need to be written
>>> like that. And unless you are familiar with the slot management
>>> internals, the "correct" pattern will not be obvious.
>>>   
>>>       
>> Only devices which direct map memory.  Currently VGA and cirrus.
>>
>>     
>
> --- /data/qemu/hw/piix_pci.c    2009-06-07 09:42:27.000000000 +0200
> +++ hw/piix_pci.c       2009-06-02 13:00:09.000000000 +0200
> ...
> @@ -91,6 +93,10 @@ static void i440fx_update_memory_mapping
>      int i, r;
>      uint32_t smram, addr;
>
> +    if (kvm_enabled()) {
> +        /* FIXME: Support remappings and protection changes. */
> +        return;
> +    }
>      update_pam(d, 0xf0000, 0x100000, (d->config[0x59] >> 4) & 3);
>      for(i = 0; i < 12; i++) {
>          r = (d->config[(i >> 1) + 0x5a] >> ((i & 1) * 4)) & 3;
>
> IIRC, this is at least partially due to the restricted slot management
> in qemu-kvm - or is this obsolete now?
>   

This is from the first days of qemu-kvm, some of this is due to Intel 
real mode issues (can't start at 0xffff ffff ffff fff0), and some I 
never got around to.  It's possible that it requires proper slot 
destruction.  Even if that's the case, we cam simply return here, as the 
code shows.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

Avi Kivity wrote:
> Jan Kiszka wrote:
>> Avi Kivity wrote:
>>  
>>> Jan Kiszka wrote:
>>>    
>>>>>> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>>>>>>  there are required as qemu-kvm tracking
>>>>>> cpu_register_physical_memory and
>>>>>>  kvm_log_start cannot cope with all the patterns normal qemu code
>>>>>> comes
>>>>>>  up with. Upstream slot management now provides the same features
>>>>>>  (including migration) like qemu-kvm, it just does not deal with
>>>>>> legacy,
>>>>>>  thus it does not have to patch qemu code (rather, we were able to
>>>>>> remove
>>>>>>  some already merged hooks - vga_dirty_log_stop).
>>>>>>                 
>>>>> Still not very restrictive, all this could be encapsulated with for
>>>>> example macro COMPAT_NO_DMRW which could be removed when we don't care
>>>>> anymore. Next?
>>>>>             
>>>> Really, it's not worth the maintenance pain: Every new device emulation
>>>> code that wants to be KVM-legacy-compatible would need to be written
>>>> like that. And unless you are familiar with the slot management
>>>> internals, the "correct" pattern will not be obvious.
>>>>         
>>> Only devices which direct map memory.  Currently VGA and cirrus.
>>>
>>>     
>>
>> --- /data/qemu/hw/piix_pci.c    2009-06-07 09:42:27.000000000 +0200
>> +++ hw/piix_pci.c       2009-06-02 13:00:09.000000000 +0200
>> ...
>> @@ -91,6 +93,10 @@ static void i440fx_update_memory_mapping
>>      int i, r;
>>      uint32_t smram, addr;
>>
>> +    if (kvm_enabled()) {
>> +        /* FIXME: Support remappings and protection changes. */
>> +        return;
>> +    }
>>      update_pam(d, 0xf0000, 0x100000, (d->config[0x59] >> 4) & 3);
>>      for(i = 0; i < 12; i++) {
>>          r = (d->config[(i >> 1) + 0x5a] >> ((i & 1) * 4)) & 3;
>>
>> IIRC, this is at least partially due to the restricted slot management
>> in qemu-kvm - or is this obsolete now?
>>   
> 
> This is from the first days of qemu-kvm, some of this is due to Intel
> real mode issues (can't start at 0xffff ffff ffff fff0), and some I
> never got around to.  It's possible that it requires proper slot
> destruction.  Even if that's the case, we cam simply return here, as the
> code shows.

But we can also get past this point as upstream demonstrates (minus
protection changes).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>> Jan Kiszka wrote:
>>     
>>> Avi Kivity wrote:
>>>  
>>>       
>>>> Jan Kiszka wrote:
>>>>    
>>>>         
>>>>>>> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>>>>>>>  there are required as qemu-kvm tracking
>>>>>>> cpu_register_physical_memory and
>>>>>>>  kvm_log_start cannot cope with all the patterns normal qemu code
>>>>>>> comes
>>>>>>>  up with. Upstream slot management now provides the same features
>>>>>>>  (including migration) like qemu-kvm, it just does not deal with
>>>>>>> legacy,
>>>>>>>  thus it does not have to patch qemu code (rather, we were able to
>>>>>>> remove
>>>>>>>  some already merged hooks - vga_dirty_log_stop).
>>>>>>>                 
>>>>>>>               
>>>>>> Still not very restrictive, all this could be encapsulated with for
>>>>>> example macro COMPAT_NO_DMRW which could be removed when we don't care
>>>>>> anymore. Next?
>>>>>>             
>>>>>>             
>>>>> Really, it's not worth the maintenance pain: Every new device emulation
>>>>> code that wants to be KVM-legacy-compatible would need to be written
>>>>> like that. And unless you are familiar with the slot management
>>>>> internals, the "correct" pattern will not be obvious.
>>>>>         
>>>>>           
>>>> Only devices which direct map memory.  Currently VGA and cirrus.
>>>>
>>>>     
>>>>         
>>> --- /data/qemu/hw/piix_pci.c    2009-06-07 09:42:27.000000000 +0200
>>> +++ hw/piix_pci.c       2009-06-02 13:00:09.000000000 +0200
>>> ...
>>> @@ -91,6 +93,10 @@ static void i440fx_update_memory_mapping
>>>      int i, r;
>>>      uint32_t smram, addr;
>>>
>>> +    if (kvm_enabled()) {
>>> +        /* FIXME: Support remappings and protection changes. */
>>> +        return;
>>> +    }
>>>      update_pam(d, 0xf0000, 0x100000, (d->config[0x59] >> 4) & 3);
>>>      for(i = 0; i < 12; i++) {
>>>          r = (d->config[(i >> 1) + 0x5a] >> ((i & 1) * 4)) & 3;
>>>
>>> IIRC, this is at least partially due to the restricted slot management
>>> in qemu-kvm - or is this obsolete now?
>>>   
>>>       
>> This is from the first days of qemu-kvm, some of this is due to Intel
>> real mode issues (can't start at 0xffff ffff ffff fff0), and some I
>> never got around to.  It's possible that it requires proper slot
>> destruction.  Even if that's the case, we cam simply return here, as the
>> code shows.
>>     
>
> But we can also get past this point as upstream demonstrates (minus
> protection changes).
>   

It's actually quite recent:

commit d03f4d2defd76f35f46f5418979f3e6d14a11183
Author: Jan Kiszka <jan.kiszka@web.de>
Date:   Wed Sep 10 21:34:44 2008 +0200

    I440fx: do change ISA mappings under KVM
   
    As long as KVM does not support remapping or protection state changes of
    guest memory, do not fiddle with the ISA mappings that QEMU see,
    confusing both the monitor and the gdbstub.
   
    Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
    Signed-off-by: Avi Kivity <avi@qumranet.com>

So we can change this to if (kvm_enabled() && 
kvm_doesnt_support_remapping_or_protection_state_changes()).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: POLL: Why do you use kqemu?

[Blue Swirl]

On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
> Blue Swirl wrote:
>  > On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
>  >> Blue Swirl wrote:
>  >>  > On 6/7/09, Jan Kiszka <jan.kiszka@web.de> wrote:
>  >>  >> Avi Kivity wrote:
>  >>  >>  > Jan Kiszka wrote:
>  >>  >>  >>> Maybe the backwards compatibility features should be ported to QEMU?
>  >>  >>  >>> For example, is there a workaround for
>  >>  >>  >>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>  >>  >>  >>> ?
>  >>  >>  >>>
>  >>  >>  >>
>  >>  >>  >> Given that we have always-up-to-date kvm-kmod packages with support down
>  >>  >>  >> to reasonable kernel versions, I would prefer to keep upstream clean
>  >>  >>  >> from old workarounds. They should only be needed for issues found very
>  >>  >>  >> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>  >>  >>  >> the future.
>  >>  >>  >>
>  >>  >>  >
>  >>  >>  > Requiring the latest up-to-date modules is pushing the problem to the
>  >>  >>  > users.  Sometimes there is no choice, but when there is, the
>  >>  >>  > implementation that cares about its uses prefer unclean code and
>  >>  >>  > functionality over perfection and brokenness.
>  >>  >>
>  >>  >>
>  >>  >> Let's make it more concrete:
>  >>  >>
>  >>  >>  By the time upstream is as well tested, feature-rich and with comparable
>  >>  >>  performance as qemu-kvm, its current baseline requirement (2.6.29 due to
>  >>  >>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most
>  >>  >>  normal users. Until then they are better off with qemu-kvm anyway.
>  >>  >>
>  >>  >>  So all I wanted to express is that I see no point in merging workarounds
>  >>  >>  upstream that hardly anyone will need but that restrict non-kvm code in
>  >>  >>  upstream. Basically I have the current line along
>  >>  >>  KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in
>  >>  >>  mind. Anything older should be skipped when merging upstream. And unless
>  >>  >>  something more problematic comes along (rather unlikely), 2.6.29 or
>  >>  >>  compatible kvm-kmod is a reasonable minimum requirement for the long term.
>  >>  >
>  >>  > I pulled qemu-kvm and it looks to me that
>  >>  > KVM_CAP_DESTROY_MEMORY_REGION_WORKS and the derived functions
>  >>  > kvm_destroy_memory_region_works() and must_use_aliases_*() are only
>  >>  > used in very few places. Do I miss something, how can this be of any
>  >>  > restriction?
>  >>
>  >>
>  >> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>  >>  there are required as qemu-kvm tracking cpu_register_physical_memory and
>  >>  kvm_log_start cannot cope with all the patterns normal qemu code comes
>  >>  up with. Upstream slot management now provides the same features
>  >>  (including migration) like qemu-kvm, it just does not deal with legacy,
>  >>  thus it does not have to patch qemu code (rather, we were able to remove
>  >>  some already merged hooks - vga_dirty_log_stop).
>  >
>  > Still not very restrictive, all this could be encapsulated with for
>  > example macro COMPAT_NO_DMRW which could be removed when we don't care
>  > anymore. Next?
>
>
> Really, it's not worth the maintenance pain: Every new device emulation
>  code that wants to be KVM-legacy-compatible would need to be written
>  like that. And unless you are familiar with the slot management
>  internals, the "correct" pattern will not be obvious.
>
>  I've just finished a patch for configure and for the runtime code to
>  tell the user what the maturer alternatives are. Will send it out in a
>  minute.

kvm-kmod seems to be available only for x86, not amd64. This is not
mentioned in README (in fact, there is no README), configure will
succeed and make will only generate funky errors. I only found this
mentioned in http://www.linux-kvm.org/page/Code after quite a bit of
head scratching.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Gleb Natapov]

On Sun, Jun 07, 2009 at 02:13:15PM +0300, Blue Swirl wrote:
> kvm-kmod seems to be available only for x86, not amd64. This is not
> mentioned in README (in fact, there is no README), configure will
> succeed and make will only generate funky errors. I only found this
> mentioned in http://www.linux-kvm.org/page/Code after quite a bit of
> head scratching.
> 
Never used kvm-kmod on x86 only with x86_64.

--
			Gleb.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Blue Swirl]

On 6/7/09, Gleb Natapov <gleb@redhat.com> wrote:
> On Sun, Jun 07, 2009 at 02:13:15PM +0300, Blue Swirl wrote:
>  > kvm-kmod seems to be available only for x86, not amd64. This is not
>  > mentioned in README (in fact, there is no README), configure will
>  > succeed and make will only generate funky errors. I only found this
>  > mentioned in http://www.linux-kvm.org/page/Code after quite a bit of
>  > head scratching.
>  >
>
> Never used kvm-kmod on x86 only with x86_64.

How do you compile it then, I only get so far:
$ make V=1
make -C /lib/modules/2.6.26-2-amd64/build M=`pwd` \
                LINUXINCLUDE="-I`pwd`/include -Iinclude \
                 \
                -Iarch/x86/include -I`pwd`/include-compat \
                -include include/linux/autoconf.h \
                -include `pwd`/x86/external-module-compat.h " \
                "$@"
make[1]: Entering directory `/usr/src/linux-headers-2.6.26-2-amd64'
test -e include/linux/autoconf.h -a -e include/config/auto.conf || (        \
        echo;                                                           \
        echo "  ERROR: Kernel configuration is invalid.";               \
        echo "         include/linux/autoconf.h or
include/config/auto.conf are missing.";   \
        echo "         Run 'make oldconfig && make prepare' on kernel
src to fix it.";       \
        echo;                                                           \
        /bin/false)
mkdir -p /tmp/kvm-kmod/.tmp_versions ; rm -f /tmp/kvm-kmod/.tmp_versions/*
make -f scripts/Makefile.build obj=/tmp/kvm-kmod
make -f scripts/Makefile.build obj=/tmp/kvm-kmod/x86
make[3]: *** No rule to make target `/tmp/kvm-kmod/x86/svm.o', needed
by `/tmp/kvm-kmod/x86/kvm.o'.  Stop.
make[2]: *** [/tmp/kvm-kmod/x86] Error 2
make[1]: *** [_module_/tmp/kvm-kmod] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.26-2-amd64'
make: *** [all] Error 2

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Gleb Natapov]

On Sun, Jun 07, 2009 at 02:26:46PM +0300, Blue Swirl wrote:
> On 6/7/09, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sun, Jun 07, 2009 at 02:13:15PM +0300, Blue Swirl wrote:
> >  > kvm-kmod seems to be available only for x86, not amd64. This is not
> >  > mentioned in README (in fact, there is no README), configure will
> >  > succeed and make will only generate funky errors. I only found this
> >  > mentioned in http://www.linux-kvm.org/page/Code after quite a bit of
> >  > head scratching.
> >  >
> >
> > Never used kvm-kmod on x86 only with x86_64.
> 
> How do you compile it then, I only get so far:
I have linux-2.6 link there to the kernel tree with latest kvm. Than I
do "make sync && make"

> $ make V=1
> make -C /lib/modules/2.6.26-2-amd64/build M=`pwd` \
>                 LINUXINCLUDE="-I`pwd`/include -Iinclude \
>                  \
>                 -Iarch/x86/include -I`pwd`/include-compat \
>                 -include include/linux/autoconf.h \
>                 -include `pwd`/x86/external-module-compat.h " \
>                 "$@"
> make[1]: Entering directory `/usr/src/linux-headers-2.6.26-2-amd64'
> test -e include/linux/autoconf.h -a -e include/config/auto.conf || (        \
>         echo;                                                           \
>         echo "  ERROR: Kernel configuration is invalid.";               \
>         echo "         include/linux/autoconf.h or
> include/config/auto.conf are missing.";   \
>         echo "         Run 'make oldconfig && make prepare' on kernel
> src to fix it.";       \
>         echo;                                                           \
>         /bin/false)
> mkdir -p /tmp/kvm-kmod/.tmp_versions ; rm -f /tmp/kvm-kmod/.tmp_versions/*
> make -f scripts/Makefile.build obj=/tmp/kvm-kmod
> make -f scripts/Makefile.build obj=/tmp/kvm-kmod/x86
> make[3]: *** No rule to make target `/tmp/kvm-kmod/x86/svm.o', needed
> by `/tmp/kvm-kmod/x86/kvm.o'.  Stop.
> make[2]: *** [/tmp/kvm-kmod/x86] Error 2
> make[1]: *** [_module_/tmp/kvm-kmod] Error 2
> make[1]: Leaving directory `/usr/src/linux-headers-2.6.26-2-amd64'
> make: *** [all] Error 2

--
			Gleb.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Blue Swirl wrote:
> On 6/7/09, Gleb Natapov <gleb@redhat.com> wrote:
>   
>> On Sun, Jun 07, 2009 at 02:13:15PM +0300, Blue Swirl wrote:
>>  > kvm-kmod seems to be available only for x86, not amd64. This is not
>>  > mentioned in README (in fact, there is no README), configure will
>>  > succeed and make will only generate funky errors. I only found this
>>  > mentioned in http://www.linux-kvm.org/page/Code after quite a bit of
>>  > head scratching.
>>  >
>>
>> Never used kvm-kmod on x86 only with x86_64.
>>     
>
> How do you compile it then, I only get so far:
> $ make V=1
> make -C /lib/modules/2.6.26-2-amd64/build M=`pwd` \
>                 LINUXINCLUDE="-I`pwd`/include -Iinclude \
>                  \
>                 -Iarch/x86/include -I`pwd`/include-compat \
>                 -include include/linux/autoconf.h \
>                 -include `pwd`/x86/external-module-compat.h " \
>                 "$@"
> make[1]: Entering directory `/usr/src/linux-headers-2.6.26-2-amd64'
> test -e include/linux/autoconf.h -a -e include/config/auto.conf || (        \
>         echo;                                                           \
>         echo "  ERROR: Kernel configuration is invalid.";               \
>         echo "         include/linux/autoconf.h or
> include/config/auto.conf are missing.";   \
>         echo "         Run 'make oldconfig && make prepare' on kernel
> src to fix it.";       \
>         echo;                                                           \
>         /bin/false)
> mkdir -p /tmp/kvm-kmod/.tmp_versions ; rm -f /tmp/kvm-kmod/.tmp_versions/*
> make -f scripts/Makefile.build obj=/tmp/kvm-kmod
> make -f scripts/Makefile.build obj=/tmp/kvm-kmod/x86
> make[3]: *** No rule to make target `/tmp/kvm-kmod/x86/svm.o', needed
> by `/tmp/kvm-kmod/x86/kvm.o'.  Stop.
> make[2]: *** [/tmp/kvm-kmod/x86] Error 2
> make[1]: *** [_module_/tmp/kvm-kmod] Error 2
> make[1]: Leaving directory `/usr/src/linux-headers-2.6.26-2-amd64'
> make: *** [all] Error 2
>   

What are you building, exactly?  Did you load the tarball from 
sourceforge, or kvm-kmod from git?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Blue Swirl]

On 6/7/09, Avi Kivity <avi@redhat.com> wrote:
> Blue Swirl wrote:
>
> > On 6/7/09, Gleb Natapov <gleb@redhat.com> wrote:
> >
> >
> > > On Sun, Jun 07, 2009 at 02:13:15PM +0300, Blue Swirl wrote:
> > >  > kvm-kmod seems to be available only for x86, not amd64. This is not
> > >  > mentioned in README (in fact, there is no README), configure will
> > >  > succeed and make will only generate funky errors. I only found this
> > >  > mentioned in http://www.linux-kvm.org/page/Code
> after quite a bit of
> > >  > head scratching.
> > >  >
> > >
> > > Never used kvm-kmod on x86 only with x86_64.
> > >
> > >
> >
> > How do you compile it then, I only get so far:
> > $ make V=1
> > make -C /lib/modules/2.6.26-2-amd64/build M=`pwd` \
> >                LINUXINCLUDE="-I`pwd`/include -Iinclude \
> >                 \
> >                -Iarch/x86/include -I`pwd`/include-compat \
> >                -include include/linux/autoconf.h \
> >                -include
> `pwd`/x86/external-module-compat.h " \
> >                "$@"
> > make[1]: Entering directory
> `/usr/src/linux-headers-2.6.26-2-amd64'
> > test -e include/linux/autoconf.h -a -e include/config/auto.conf || (
>  \
> >        echo;                                                           \
> >        echo "  ERROR: Kernel configuration is invalid.";               \
> >        echo "         include/linux/autoconf.h or
> > include/config/auto.conf are missing.";   \
> >        echo "         Run 'make oldconfig && make prepare' on kernel
> > src to fix it.";       \
> >        echo;                                                           \
> >        /bin/false)
> > mkdir -p /tmp/kvm-kmod/.tmp_versions ; rm -f /tmp/kvm-kmod/.tmp_versions/*
> > make -f scripts/Makefile.build obj=/tmp/kvm-kmod
> > make -f scripts/Makefile.build obj=/tmp/kvm-kmod/x86
> > make[3]: *** No rule to make target `/tmp/kvm-kmod/x86/svm.o', needed
> > by `/tmp/kvm-kmod/x86/kvm.o'.  Stop.
> > make[2]: *** [/tmp/kvm-kmod/x86] Error 2
> > make[1]: *** [_module_/tmp/kvm-kmod] Error 2
> > make[1]: Leaving directory
> `/usr/src/linux-headers-2.6.26-2-amd64'
> > make: *** [all] Error 2
> >
> >
>
>  What are you building, exactly?  Did you load the tarball from sourceforge,
> or kvm-kmod from git?

git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Blue Swirl wrote:
>>  What are you building, exactly?  Did you load the tarball from sourceforge,
>> or kvm-kmod from git?
>>     
>
> git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
>   

That doesn't include the sources - it's only a kit that backports the 
sources so they can run on older kernels.

Either download a tarball, or do

$ cd kvm-kmod
$ git submodule update --init
(wait)
$ ./configure
$ make sync
$ make

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Gleb Natapov]

On Sun, Jun 07, 2009 at 03:43:42PM +0300, Avi Kivity wrote:
> Blue Swirl wrote:
>>>  What are you building, exactly?  Did you load the tarball from sourceforge,
>>> or kvm-kmod from git?
>>>     
>>
>> git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
>>   
>
> That doesn't include the sources - it's only a kit that backports the  
> sources so they can run on older kernels.
>
> Either download a tarball, or do
>
> $ cd kvm-kmod
> $ git submodule update --init
Is this step mandatory or can I link to existing kernel source instead?

> (wait)
> $ ./configure
> $ make sync
> $ make
>
> -- 
> Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
			Gleb.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Gleb Natapov wrote:
>> That doesn't include the sources - it's only a kit that backports the  
>> sources so they can run on older kernels.
>>
>> Either download a tarball, or do
>>
>> $ cd kvm-kmod
>> $ git submodule update --init
>>     
> Is this step mandatory or can I link to existing kernel source instead?
>   

You can probably us ln -s, haven't tried.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Blue Swirl]

On 6/7/09, Avi Kivity <avi@redhat.com> wrote:
> Blue Swirl wrote:
>
> >
> > >  What are you building, exactly?  Did you load the tarball from
> sourceforge,
> > > or kvm-kmod from git?
> > >
> > >
> >
> > git clone
> git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
> >
> >
>
>  That doesn't include the sources - it's only a kit that backports the
> sources so they can run on older kernels.
>
>  Either download a tarball, or do
>
>  $ cd kvm-kmod
>  $ git submodule update --init
>  (wait)
>  $ ./configure
>  $ make sync
>  $ make

Ok, now I got the module installed and after I copied stuff under
include to /usr/local/include, QEMU detects KVM successfully.

I found a bug in configure, if there are targets that can't use KVM,
it is disabled for all targets.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

Blue Swirl wrote:
> On 6/7/09, Avi Kivity <avi@redhat.com> wrote:
>> Blue Swirl wrote:
>>
>>>>  What are you building, exactly?  Did you load the tarball from
>> sourceforge,
>>>> or kvm-kmod from git?
>>>>
>>>>
>>> git clone
>> git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
>>>
>>  That doesn't include the sources - it's only a kit that backports the
>> sources so they can run on older kernels.
>>
>>  Either download a tarball, or do
>>
>>  $ cd kvm-kmod
>>  $ git submodule update --init
>>  (wait)
>>  $ ./configure
>>  $ make sync
>>  $ make
> 
> Ok, now I got the module installed and after I copied stuff under
> include to /usr/local/include, QEMU detects KVM successfully.
> 
> I found a bug in configure, if there are targets that can't use KVM,
> it is disabled for all targets.

Not for me here (when using the default target list).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity]

Blue Swirl wrote:
> I found a bug in configure, if there are targets that can't use KVM,
> it is disabled for all targets.
>   

Yes.  kvm support should be an array, not a scalar.  Note we shouldn't 
even attempt kvm if the host and target don't match. 

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Avi Kivity wrote:
> Blue Swirl wrote:
>> I found a bug in configure, if there are targets that can't use KVM,
>> it is disabled for all targets.
>>   
>
> Yes.  kvm support should be an array, not a scalar.  Note we shouldn't 
> even attempt kvm if the host and target don't match.

It doesn't need to be an array.  Something like this should work.

Regards,

Anthony Liguori

[-- Attachment #2: kvm-configure.patch --]
[-- Type: text/x-patch, Size: 2494 bytes --]

commit 75081cfc8a0cba8fe1760f8fc861c3dc3fba6fd1
Author: Anthony Liguori <aliguori@us.ibm.com>
Date:   Sun Jun 7 13:35:41 2009 -0500

    Don't globally disable kvm if one target doesn't support it
    
    When iterating through each element in target_list, we disable kvm if we find
    a target that doesn't support kvm.  This means that kvm can get globally
    disabled when configuring with multiple targets.
    
    Instead, use a new variable, has_kvm, to indicate whether the target has kvm
    support or not.
    
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

diff --git a/configure b/configure
index 6ab4d80..f89327c 100755
--- a/configure
+++ b/configure
@@ -1828,16 +1828,18 @@ interp_prefix1=`echo "$interp_prefix" | sed "s/%M/$target_cpu/g"`
 echo "#define CONFIG_QEMU_PREFIX \"$interp_prefix1\"" >> $config_h
 gdb_xml_files=""
 
+has_kvm="$kvm"
+
 # Make sure the target and host cpus are compatible
 if test "$kvm" = "yes" -a ! \( "$target_cpu" = "$cpu" -o \
   \( "$target_cpu" = "ppcemb" -a "$cpu" = "ppc" \) -o \
   \( "$target_cpu" = "x86_64" -a "$cpu" = "i386"   \) -o \
   \( "$target_cpu" = "i386"   -a "$cpu" = "x86_64" \) \) ; then
-  kvm="no"
+  has_kvm="no"
 fi
 # Disable KVM for linux-user
 if test "$kvm" = "yes" -a "$target_softmmu" = "no" ; then
-  kvm="no"
+  has_kvm="no"
 fi
 
 case "$target_cpu" in
@@ -1850,7 +1852,7 @@ case "$target_cpu" in
       echo "CONFIG_KQEMU=yes" >> $config_mak
       echo "#define CONFIG_KQEMU 1" >> $config_h
     fi
-    if test "$kvm" = "yes" ; then
+    if test "$has_kvm" = "yes" ; then
       echo "CONFIG_KVM=yes" >> $config_mak
       echo "KVM_CFLAGS=$kvm_cflags" >> $config_mak
       echo "#define CONFIG_KVM 1" >> $config_h
@@ -1872,7 +1874,7 @@ case "$target_cpu" in
       echo "CONFIG_KQEMU=yes" >> $config_mak
       echo "#define CONFIG_KQEMU 1" >> $config_h
     fi
-    if test "$kvm" = "yes" ; then
+    if test "$has_kvm" = "yes" ; then
       echo "CONFIG_KVM=yes" >> $config_mak
       echo "KVM_CFLAGS=$kvm_cflags" >> $config_mak
       echo "#define CONFIG_KVM 1" >> $config_h
@@ -1949,7 +1951,7 @@ case "$target_cpu" in
     echo "#define TARGET_ARCH \"ppcemb\"" >> $config_h
     echo "#define TARGET_PPC 1" >> $config_h
     echo "#define TARGET_PPCEMB 1" >> $config_h
-    if test "$kvm" = "yes" ; then
+    if test "$has_kvm" = "yes" ; then
       echo "CONFIG_KVM=yes" >> $config_mak
       echo "KVM_CFLAGS=$kvm_cflags" >> $config_mak
       echo "#define CONFIG_KVM 1" >> $config_h

Re: [Qemu-devel] Re: POLL: Why do you use kqemu?

[Blue Swirl]

On 6/7/09, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Avi Kivity wrote:
>
> > Blue Swirl wrote:
> >
> > > I found a bug in configure, if there are targets that can't use KVM,
> > > it is disabled for all targets.
> > >
> > >
> >
> > Yes.  kvm support should be an array, not a scalar.  Note we shouldn't
> even attempt kvm if the host and target don't match.
> >
>
>  It doesn't need to be an array.  Something like this should work.

Actually, I committed an almost identical patch 5 hours ago.