| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 0/7] merge some xen bits into qemu
People unfamiliar with the context should note that Gerd's submission
is NOT `merging some Xen bits into qemu'. The code that Gerd is
submitting is VERY SUBSTANTIALLY DIFFERENT from the code which exists
in the Xen version of qemu.
Gerd Hoffmann writes ("[Xen-devel] [PATCH 0/7] merge some xen bits into qemu"):
> The console and framebuffer backend drivers are largely based on the
> xen code, the other bits are rewritten from scratch. Nevertheless
> the code should be functionally identical.
I'm afraid I'm still opposed to the approach you are taking here.
The correct route for Xen support for qemu is via qemu-xen-unstable,
not directly into upstream qemu.
If you want to generalise the backend driver machinery, which in
qemu-xen-unstable is used only for the framebuffer, you should submit
your generalised backend machinery on qemu-devel. We will review it
and include it (when it is of appropriate quality).
Then when we have the Xen-specific structure and interfaces properly
supported, it would be right to submit parts to qemu upstream. This
will form a good basis for your other backend drivers (which are not
useful in the context of a real Xen setup).
> With first next four patches in place upstream qemu can replace xen's
> qemu-dm for paravirtual domains. Due to some small differences in
> the command line syntax it can't work as drop-in replacement though.
qemu-dm is hardly used for paravirtual domains so this is not really
very helpful. qemu-dm is not even used at all for most PV domains.
The main purpose of qemu-dm is for HVM domains.
Command-line differences are not very important in the grand scheme of
things but they too need to come through xen-devel so that there is a
sane transition.
> The last three patches add full userspace implementations of block and
> nic backend drivers using the grant table device (gntdev) and command
> line support config support for setting up these backends.
>
> xen support is implemented using another machine type. xen's qemu-dm
> already uses the machine type to switch between paravirtualized and
> fully virtualized machines, so this was the natural choice. qemu
> gets a new "xenpv" machine type additionally to the "pc" and "isapc"
> ones.
For the avoidance of any doubt, Gerd's machine types are for
_emulating_ a Xen environment on a machine without a real Xen
hypervisor.
Gerd: Why do I keep having to repeat this point ? Your messages
always obscure it.
So in summary: Gerd, please post your suggestions to xen-devel only
and explain what the purpose of each patch is.
If their intended use is for a system with a real Xen hypervisor and
xend, and the patches makes sense, then we will of course take them.
If the intended use is to clean up the code so that it will be easier
for you to fit in your simulated-Xen support then that is fine too,
but the patches must go through xen-devel and be discussed there in
that context. When we have agreed on and committed changes in
qemu-xen-unstable, it will be appropriate to submit those to
qemu-devel.
In any case, we do not want any huge upheavals in this area that are
not dealt with appropriately through the Xen testing and release
processes. We definitely don't want to have replacements of whole
swathes of our existing code appear in qemu upstream!
Please stop crossposting to qemu-devel; it is just causing confusion.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home