[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Spice-devel] viewing continuous guest virtual memory a
From: |
Alon Levy |
Subject: |
Re: [Qemu-devel] [Spice-devel] viewing continuous guest virtual memory as continuous in qemu |
Date: |
Mon, 3 Oct 2011 10:37:55 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Oct 03, 2011 at 10:17:59AM +0200, Yonit Halperin wrote:
> On 10/02/2011 03:24 PM, Alon Levy wrote:
> >Hi,
> >
> > I'm trying to acheive the $subject. Some background: currently spice
> > relies on a preallocated pci bar for both surfaces and for VGA framebuffer
> > + commands. I have been trying to get rid of the surfaces bar. To do that I
> > allocate memory in the guest and then translate it for spice-server
> > consumption using cpu_physical_memory_map.
> >
> > AFAIU this works only when the guest allocates a continuous range of
> > physical pages. This is a large requirement from the guest, which I'd like
> > to drop. So I would like to have the guest use a regular allocator,
> > generating for instance two sequential pages in virtual memory that are
> > scattered in physical memory. Those two physical guest page addresses (gp1
> > and gp2) correspond to two host virtual memory addresses (hv1, hv2). I
> > would now like to provide to spice-server a single virtual address p that
> > maps to those two pages in sequence. I don't want to handle my own
> > scatter-gather list, I would like to have this mapping done once so I can
> > use an existing library that requires a single pointer (for instance pixman
> > or libGL) to do the rendering.
> >
> > Is there any way to acheive that without host kernel support, in user
> > space, i.e. in qemu? or with an existing host kernel device?
> >
> > I'd appreciate any help,
> >
> >Alon
> >_______________________________________________
> >Spice-devel mailing list
> >address@hidden
> >http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> Hi,
> won't there be an overhead for rendering on a non continuous
> surface? Will it be worthwhile comparing to not creating the
> surface?
If I use a scatter-gather list there is overhead of allocating and
copying the surface whenever I want to synchronize. Minimally once
to copy from guest to host, and another copy from host to guest
for any update_area. (we can only copy the required area.
If I use page remapping like remap_file_pages does, I don't think
there is any overhead for rendering. There is overhead for doing
the remap_file_pages calls, but they are minimal (or so the man page
says). I should benchmark this.
The additional cost is not large - I suppose rendering should be more
costly then a memcpy. But the question is true regardless of this -
some surfaces should be punted probably, if we had an oracle to know they
would be immediately update_area'ed and destroyed.
>
> BTW. We should test if the split to vram (surfaces) and devram
> (commands and others) is more efficient than having one section.
> Even if it is more efficient, we can remove the split and give to
> the surfaces higher allocation priority on a part of the pci bar.
> Anyway, by default, we can try allocating surfaces on the guest RAM.
> If it fails, we can try to allocate on the pci-bar.
>
Right. What I was aiming at is removing the BAR all together. This reduces
per vm allocation, and we can still ensure a maximum via the driver. It
also reduces PCI requirements, which are a problem with more then one card.
Actually the more productive thing for reducing PCI memory would be to change
to a single card for multiple monitor support. Another reason for allocating
on guest RAM is to make migration simpler (but I'm not sure it really is).
> Cheers,
> Yonit.
>
>