public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH 7/7] Allow KVM from a normal QEMU binary
Date: Sun, 05 Nov 2006 12:18:04 -0600	[thread overview]
Message-ID: <454E2ADC.1060607@cs.utexas.edu> (raw)
In-Reply-To: <454E23EE.7040505-atKUWr5tajBWk0Htik3J/w@public.gmane.org>

Avi Kivity wrote:
> Anthony Liguori wrote:
>> One of the things I was thinking of doing was getting rid of USE_KVM 
>> completely.  What I was thinking of doing is moving kvmctl.[ch] into 
>> the QEMU tree
>
> I'd like to keep kvmctl out, so that non-qemu based userspace can be 
> built.  True, I wouldn't like to be the one to do it, but I'd like to 
> keep the possibility open.

Yeah, I'm on the fence myself.  In the very least, we need a smarter 
configure check in QEMU to detect the presence of libkvm and enable the 
define appropriately.

I'll go as far as to say that once there's proper configure checks (and 
kvm fails gracefully), it would be appropriate to send it to 
qemu-devel.  What are your thoughts?

>>> Now, the "big real" fiasco means that we need some sort of 
>>> emulation, but I'm not sure the qemu cpu loop is the best choice.  
>>> Qemu is very complex because it is geared to multi-host, 
>>> multi-target, high-performance emulation.  The cpu state is baroque, 
>>> and SMP isn't going to be fun.
>>
>> Right.
>>
>>> I think we're better off with taking the x86 emulator from the 
>>> kernel and extending it to support the non-memory instructions.  It 
>>> can run in the kernel or userspace since there's no performance 
>>> requirement.
>>
>> This is the opposite strategy that Xen is taking FWIW.  You not only 
>> need a full 16 bit emulator but a 32 bit emulator too (to deal with 
>> the transitions to/from userspace).
>
> We need a real-mode emulator.  That includes 16 and 32 bits (via 
> prefixes).
>
> We already have some significant fraction of it in x86_emulator.c.  
> Whether to extend it (in the kernel or in userspace) or to use some 
> other emulator is a good question.  Of course, we can use qemu, but 
> that's fairly complex.
>
>>
>> The tree we're working in is:
>>
>> http://xenbits.xensource.com/ext/xen-unstable-hvm.hg
>>
>> Linux kernel boots quite nicely and I'm in the process of debugging 
>> why Windows guests aren't booting (there appears to be a problem in 
>> the state transfer right now).
>
> State transfer is what turned us of qemu.  Reconstructing the state 
> (esp. eflags and the segments) is quite difficult and there are some 
> annoying qemu bugs (like the busy task flag checks).

The Xen tree already has the conversion code.  It's annoying but it's 
not nearly as bad as say, shadow paging :-)

While not necessarily in your scope, in the long term, having the state 
transfer would be really useful.

I can imagine KVM eventually supporting VT, SVM, user mode 
virtualization, and paravirtualization. State transfer use is useful for 
VT at least but is absolutely required for user mode virtualization.  
All of these things exist in some form right now (user mode via qvm86 
and para via lhype) and all are duplicating a lot of tough code (such as 
shadow paging).

Of course, state transfer won't be impossible to add down the road at 
some point so if you think big real mode will be easier with emulation, 
it wouldn't be that bad to give it a shot.

> BTW, dumping qemu cpu emulation will allow us to use gcc 4.x instead 
> of gcc 3.x.
>
>>
>> SMP guest support is still a hard problem that needs thinking through 
>> but if Xen solves it, KVM can use the solution (or vice versa).
>
> I don't see a huge problem.  We'll have to get the APIC right, and the 
> mmu locking right in the kernel, but what else?

It's not so bad provided you don't use QEMU for emulation.  That's what 
I was referring to.  There are some tricky cases where QEMU is accessing 
a piece of memory with an atomic instruction while another VCPU is 
running on bare metal and trying to touch the same memory.  I suspect 
that as-is, QEMU would violate the atomic guarantees when it translates 
the instruction.

Regards,

Anthony Liguori

>>
>> Don't discount the importance of 16 bit emulation performance.  I use 
>> QEMU a lot to play old DOS games :-)
>
> We'll add an option to udelay() in strategic places :)
>


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

  parent reply	other threads:[~2006-11-05 18:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-03  6:21 [PATCH 0/7] Split up QEMU patches Anthony Liguori
     [not found] ` <454AE007.5070905-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
2006-11-03  6:25   ` [PATCH 1/7] Compile fix for usb-linux.c Anthony Liguori
2006-11-03  6:26   ` [PATCH 2/7] APIC save/restore fix Anthony Liguori
2006-11-03  6:27   ` [PATCH 3/7] Timer " Anthony Liguori
2006-11-03  6:29   ` [PATCH 4/7] gdbstub for x86-64 Anthony Liguori
2006-11-03  6:30   ` [PATCH 5/7] VMDK Snapshot Support Anthony Liguori
2006-11-03  6:31   ` [PATCH 6/7] KVM changes for QEMU Anthony Liguori
2006-11-03  6:35   ` [PATCH 7/7] Allow KVM from a normal QEMU binary Anthony Liguori
     [not found]     ` <454AE323.8090309-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
2006-11-05  9:27       ` Avi Kivity
     [not found]         ` <454DAE74.4030306-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2006-11-05 17:28           ` Anthony Liguori
     [not found]             ` <454E1F40.2070200-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
2006-11-05 17:48               ` Avi Kivity
     [not found]                 ` <454E23EE.7040505-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2006-11-05 18:18                   ` Anthony Liguori [this message]
     [not found]                     ` <454E2ADC.1060607-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
2006-11-05 18:29                       ` Avi Kivity
     [not found]                         ` <454E2DA4.8070405-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2006-11-05 19:53                           ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=454E2ADC.1060607@cs.utexas.edu \
    --to=aliguori-nzps4cjig2hvqtjrzfazuq@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox