[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Error restoring DomU when using GPLPV

On 20/08/2009 11:19, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> No, not really. We could add a xenstore flag or something I suppose. But
> really losing a few memory pages is not the end of the world. I suppose the
> major pain might be if it shatters a physical superpage, and hence makes
> VT-d/EPT type stuff more expensive. If you could at least arrange for the
> pages to come from the same aligned 2MB region, or even from the bottom 2MB
> of memory (which can never be allocated as a superpage because of the VGA
> area), that might be nice.
> Thinking about how to fix this nicely in the tools, it seems pretty tricky
> if I don't want to have to change the dom0 kernel too. The kernel is quite
> involved in mapping foreign pages up to user space and gets in the way of
> hacking in a flag between tools and Xen... And we do want to be able to map
> foreign Xen-heap pages in some cases. It's only a nuisance for
> xc_domain_save.

Another method would be for the PV-on-HVM drivers to map shinfo and gnttab
pages in a restricted guest-physical address range and then advertise the
range via, say, a new HVMPARAM. Tools could also indicate to PV-on-HVM that
this method is supported via the same HVMPARAM.

How does that sound? It would give the ability for a general exclusion range
for save/restore.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.