|
xen-devel
Re: [Xen-devel] Re: [Qemu-devel] [PATCH 1/7] xen: groundwork for xen sup
Gerd Hoffmann wrote:
Anthony Liguori wrote:
map-cache is one of those things I don't expect to ever get merged.
And the need for that will go away over time IMHO. If your Dom0 is
64bit you have no address space pressure and thus no need for mapcache.
Given we have 32-on-64 and non-PAE Xen is depricated anyway there is
almost no reason to not run 64bit Xen and Dom0.
Right.
Ideally, I'd like to see Xen/KVM integration look like this:
1) Xen support is detected in configure (libxc et al) and conditionally
enabled.
2) When running on bare metal, detect whether KVM acceleration is
available, also detect if kqemu acceleration is available
3) When running under Xen, detect that Xen is available, and create a
full virt domain
4) If a user specifies a type=xen device, it should Just Work provided
you are in a Xen environment (erroring appropriately)
5) A user can explicitly specify -M xenpv. If running under Xen, this
would create a Xen PV guest. If running on bare metal, Xenner would be
used to present a Xen shim layer. This should work with KVM
acceleration or without KVM acceleration. Bonus points if it works with
kqemu too.
I'm surprised how well you can read my mind.
Scary, huh? :-)
Yes, I wanna have the bonus points ;)
There are two additional points you didn't see though:
For (3) and (5) qemu should support two modes: First, attach to an
existing domain. This is how Xen works today. And we want get rid of
the qemu-dm fork, right? Second, optionally also create the domain,
like Xenite.
I have mixed feelings about this, but I don't think there's a way to
support stub domains without this functionality. Obviously, when you
run QEMU within a stub domain, the guest domain has already been
created. Well, maybe it doesn't have to be that way but it seems most
reasonable to do it that way.
(4) should also just work when you are *not* in a Xen environment[1]
I considered suggesting that but figured it would be too much. I should
have figured it was already working in some form :-)
So how does the upstream Xen community feel about all of this? Is this
a reasonable approach to merging Xen functionality into QEMU?
Regards,
Anthony Liguori
cheers,
Gerd
[1] It actually does, btw. Code isn't ready yet for merging.
Stay tuned ;)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home