| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [Qemu-devel] xen / qemu convergence ?
On 17/12/2007, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> 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 ?
There's currently no way in qemu to map a chunk of host memory to
guest memory 1:1 if it's not in phys_ram_base, so all video adapters
in qemu do that. Mapped memory that's part of phys_ram_base also gets
dirty pages tracking for free. A way to map any arbitrary host address
to guest RAM would be useful for cases like the vmware-svga where no
dirty tracking is needed if the SDL framebuffer is made directly
accessible to guest.
Cirrus and stdvga code in qemu appears to do exactly the same thing,
I'm not sure why there is a difference between the two in Xen.
Regards
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home