[Xen-devel] [RFC] Handling video ram in libxendevicemodel

[Wei Liu <wei.liu2@xxxxxxxxxx>]

Hi all

I picked up Ian Campbell's work on introducing a set of stable
libraries that can be used by user space programs. The latest one is
libxendevicemodel which is designed to be used by, well, device model.
The last obstacle for it (without PCI passthrough support) is
video ram handling.

I thought about it a bit but wasn't sure about the best approach
forward. QEMU is the only device model that I know of and it does
things in very specific manner. Any mechanism derived from looking at
QEMU along risks not generic enough for other users. On the other
hand, I don't want to over-design.

So far I have two possible approaches in mind. One is to have some
sort of vram abstraction inside the library. The other is no vram
abstraction at all. I will just paste in the relevant declarations
here. Note, there is a set of APIs to manipulate guest memory in
libxendevicemole at this point.

Approach one: vram abstraction inside libxendevicemodel.

We provide a set of APIs to deal with vram:

/*
 * Populate a region of video RAM starting at vram_start_gpfn by
 * taking nr_pages of backing memory from backing_start_pgfn onwards.
 *
 * The guest physical memory region at backing_start_gpfn must
 * currently be populated with regular memory (such as that from
 * xendevicemodel_populate_ram) and will become unmapped as a result
 * of this call.
 *
 * The memory region will be given appropriate cache properties for
 * video RAM.
 *
 * On success *r_vram will be set to an opaque cookie.
 *
 * XXX
 *
 * This is tied to how QEMU does things (it first allocates ram then
 * moves it around) . Other (future) device model might just use an API
 * to allocate a region and be done with it?
 */

struct xendevicemodel_vram;
int xendevicemodel_create_vram_region(xendevicemodel_handle *dm,
                                      xen_pfn_t vram_start_gpfn,
                                      xen_pfn_t backing_start_gpfn,
                                      size_t nr_pages,
                                      struct xendevicemodel_vram **r_vram);

/*
 * Track dirty bitmap from start to (start+length). The region must be
 * part of the vram.
 */
int xendevicemodel_vram_dirtybitmap(xendevicemodel_handle *dm,
                                    struct xendevicemodel_vram *vram,
                                    xen_pfn_t start, size_t length);

/*
 * Undoes (perhaps partially) the effects of a previous
 * xendevicemodel_populate_vram. Memory which was previously moved
 * from backing_start_gpfn to vram_start_gpfn will be returned to its
 * original location.
 *
 * The address space at vram_start_gpfn will become unmapped and the
 * memory at backing_start_gpfn will have cache properties suitable
 * for standard RAM.
 *
 * probably undo the cacheattr, done on populate, which current QEMU
 * code does not do.
 *
 * XXX
 * There is no guarantee that moving the memory back to where it
 * was would succeed. There won't be any user of this API because QEMU
 * doesn't destroy vram. Maybe we shouldn't have this at all until a
 * real user shows up?
 */
int xendevicemodel_destroy_vram(xendevicemodel_handle *dm,
                                struct xendevicemodel_vram *vram,
                                xen_pfn_t vram_start_gpfn,
                                xen_pfn_t backing_start_gpfn,
                                size_t nr_pages);


Approach two: no vram abstraction.

/* Move nr_pages from orig_gpfn to new_gpfn
 *
 * XXX
 * The reason for having API to move ram around is because QEMU
 * populates ram and then moves it to vram region. This is a useful
 * API to have in general though.
 *
 */
int xendevicemodel_move_ram_region(xendevicemodel_handle *dm,
                                   xen_pfn_t orig_gpfn, xen_pfn_t new_gpfn,
                                   unsigned int nr_pages);

/*
 * Pin pages with cache attribute suitable for vram.
 *
 * XXX
 * Need to provide an unpin API? We can't get cache attribute from
 * hypervisor at the moment. And there won't be any user of unpin API
 * because QEMU won't use it.
 */
int xendevicemodel_pin_vram_cacheattr(xendevicemodel_handle *dm,
                                      xen_pfn_t gpfn_start,
                                      unsigned int nr_pages);

/*
 * Track vram dirty bitmap.
 *
 * XXX
 *
 * Without vram abstraction it doesn't check if the region is actually
 * vram. The user of this API is responsible for not messing it. But,
 * I think this wouldn't be a problem because device model needs to
 * maintain a view of guest memory anyway.
 */
int xendevicemodel_track_dirty_vram(xendevicemodel_handle *dm,
                                    xen_pfn_t gpfn_start, unsigned int nr_pages,
                                    unsigned long *bitmap);


All in all, both approaches seem to unsatisfactory -- see the lines
marked with "XXX". I would like to have some input from the community
what they would expect from libxendevicemodel. I'm slightly leaning
towards approach #2 because it is not tied to QEMU.

Comments are welcome!

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel