| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [Qemu-devel] xen / qemu convergence ?
Paul Brook writes ("Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and
> restore vram buffer (revised)"): If you look closer, you'll find
> that s->vram_ptr actually points to an offset from phys_ram_base. So
> the VGA framebuffer is already saved by ram_save.
Oh yes. That's not the case in the Xen version. I'll explain a bit
more below.
> If the xen patches have changed this then you may need your patch. It has no
> business in mainstream qemu though.
Yes, you appear to be right.
The Xen patches are far too big. (To be honest, it looks rather like
they've been done with rather less care to avoid merge disruption than
I would have liked.)
I think it would be worthwhile trying to make them smaller. Would
there be any interest in trying to converge somewhat ? At the moment
the two trees are pretty badly diverged and cross-porting fixes of any
kind is very hard (and leads to these kind of mistakes).
I certainly wouldn't suggest importing the Xen patches wholesale (or
even piecemeal) into qemu. They're quite unsuitable. But I think
that there are potential improvements to qemu's flexibility which
would be valuable for the kinds of uses found in Xen.
To explain why there is a need for any divergence at all:
Xen obviously uses only some parts of qemu. Other parts of qemu's
functionality are supplanted by hardware features and/or Xen
facilities. The main part that is applicable to the Xen situation is
the library of emulated hardware in hw/*.
It might be nice to try to make it easier to untangle these from the
core of qemu's emulation ? That might benefit other virtualisation
techniques (or indeed other weird uses for qemu's excellent library of
hardware emulations). I don't think a fully plug-and-play approach is
viable in the foreseeable future but there would be things that qemu
could do that would reduce divergence.
I think we should be able to arrange that than wholesale and intrusive
changes, the Xen tree would entirely replace, or in omit, whole files
- diverging or disconnecting at reasonably small interfaces - and
perhaps use a few different build options. Many of the existing Xen
patches would have to be reworked (or could be dropped) but I think
that would be of benefit for the Xen tree.
If there's any interest in this from the qemu side I think this would
be a worthwhile approach to try to aim for.
On to the technicalities of this particular case:
Xen's qemu has had qemu_ram_alloc completely removed. This is because
in the Xen architecture, the qemu instance is not responsible for
allocating physical guest memory and is not capable of even accessing
it other than via cpu_physical_memory_rw (whose implementation now
arranges for the necessary memory mappings etc.)
So in the Xen case device emulators ought not to use qemu_ram_alloc.
The only device used by the pc system emulator in qemu which does so
at the moment is vga, by virtue of special handling in pc_init1. (The
BIOS is done that way too but I don't regard that as a device and in
any case it's trivial.)
In the Xen version, this special handling for the emulated VGA memory
has been removed. Instead, vga_init calls qemu_malloc to get vram_ptr
(with a bit of extra code to get correct alignment). Obviously that
doesn't produce memory which will be saved so Xen's vga has to do that
itself. Xen's Cirrus emulation is the same, but _does_ save the video
memory.
I don't really understand why the vga is handled in this way in qemu
but then I'm not an expert on PC graphics hardware. Is it necessary
or desirable for the VGA RAM to take up virtual address space in this
way, or is there some other reason why VGA RAM in the ordinary vga
driver is regarded as a special use of system RAM rather than as a
special kind of hardware device ?
Regards,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home