Re: [Qemu-devel] xen / qemu convergence ?
andrzej zaborowski writes ("Re: [Qemu-devel] xen / qemu convergence ?"):
> 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.
Right. The Xen versions of the vga emulators don't map the vga ram
into the guest's address space wholesale. Accesses to the vga ram all
use the I/O callbacks through the traditional vga memory window. To
improve the performance there's (in as-yet-unreleased versions of Xen)
a Xen-specific shadow memory arrangement which tracks the guest's
writes. (I haven't looked into that in detail.)
(And of course in the Xen case, there is no host memory corresponding
to ordinary guest ram.)
> 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.
It's just a mistake: the Cirrus emulator had been changed to save its
private memory, but the corresponding required change to stdvga had
been overlooked.
Paul Brook writes ("Re: [Qemu-devel] xen / qemu convergence ?"):
> RAM is RAM. We don't care whether it's nominally owned by the vga controller
> or the "system". If you don't do this then all accesses have to go via
> horribly slow IO callbacks, which is just silly.
I see, yes.
> I've no idea what you're talking about when you say it's "taking up virtual
> address space".
I meant that it allocates part of the space indexed by ram_addr_t but
on rereading the code I think that's not visible to the guest and is
just used for qemu's own bookkeeping so I was mistaken.
Thanks,
Ian.
Re: [Qemu-devel] xen / qemu convergence ?
> 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 ? RAM is RAM. We don't care whether it's nominally owned by the vga controller or the "system". If you don't do this then all accesses have to go via horribly slow IO callbacks, which is just silly. I've no idea what you're talking about when you say it's "taking up virtual address space". Paul
Re: [Qemu-devel] xen / qemu convergence ?
On 17/12/2007, Ian Jackson <[EMAIL PROTECTED]> 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
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.
