From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Anthony Liguori <aliguori-NZpS4cJIG2HvQtjrzfazuQ@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 20:29:56 +0200 [thread overview]
Message-ID: <454E2DA4.8070405@qumranet.com> (raw)
In-Reply-To: <454E2ADC.1060607-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
Anthony Liguori wrote:
> 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?
Qemu-devel has been strangely nonresponsive to my patches (the x86-64
gdb patch was sent at least two months ago). Maybe as a known
contributor they'll be more responsive to you.
The only other issue is how stable the interface is. I think that the
kvmctl interface is almost there (I'd like to add a libkvm_open() and
libkvm_close(), have kvm_create() use the context returned from
libkvm_open(), and not create a vcpu and memory in kvm_create(), but
these are fairly cosmetic).
The kernel interface is another matter. I want to apply Arnd's
suggestions, but that's some time off. If we don't push libkvm/kvmctl
to qemu then that's not an issue.
>>
>> 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 :-)
Well, a nice property of real mode is that it doesn't use 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.
What is user mode virtualization in this context?
> 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).
Please elaborate.
>
> 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.
>
We already had real mode (and 16-bit protected, and 32-bit protected)
during development. It should be very easy to add it back. I'm worried
about maintenance and things like smp.
>> 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.
Ok. We're on the same cacheline then. An emulator definitely solves this.
(though I can't see real-mode locked instructions happening... maybe
that's an issue with qemu emulating multiple instructions for Xen during
mmio)
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
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
next prev parent reply other threads:[~2006-11-05 18:29 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
[not found] ` <454E2ADC.1060607-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
2006-11-05 18:29 ` Avi Kivity [this message]
[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=454E2DA4.8070405@qumranet.com \
--to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
--cc=aliguori-NZpS4cJIG2HvQtjrzfazuQ@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.