On 2012-01-05 15:50, Avi Kivity wrote: >> Let me summarize what we have come up with so far: >> >> - we move the call to xen_register_framebuffer before >> memory_region_init_ram in vga_common_init; >> >> - we prevent xen_ram_alloc from allocating a second framebuffer on >> restore, checking for mr == framebuffer; >> >> - we avoid memsetting the framebuffer on restore (useless anyway, the >> videoram is going to be loaded from the savefile in the general case); >> >> - we introduce a xen_address field to cirrus_vmstate and we use it >> to map the videoram into qemu's address space and update vram_ptr in >> cirrus_post_load. >> >> >> Does it make sense? Do you agree with the approach? > > Yes and yes.
To me this still sounds like a cirrus-only xen workaround that nevertheless spreads widely. Again, what speaks against migrating the information Xen needs before creating the machine or a single device? That would only introduce a generic concept of an (optional) "early", let's call it "accelerator-related" vmstate and would allow Xen to deal with all the specifics behind the curtain. Jan
signature.asc
Description: OpenPGP digital signature
