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

Re: [Xen-devel] [PATCH RFCv3 0/8] toolstack-based approach to pvhvm guest kexec



On 07/10/14 14:10, Vitaly Kuznetsov wrote:
> Changes from RFC/WIPv2:
> 
> Here is a slightly different approach to memory reassignment. Instead of
> introducing new (and very doubtful) XENMEM_transfer operation introduce
> simple XEN_DOMCTL_set_recipient operation and do everything in 
> free_domheap_pages()
> handler utilizing normal domain destroy path. This is better because:
> - The approach is general-enough
> - All memory pages are usually being freed when the domain is destroyed
> - No special grants handling required
> - Better supportability

I like this idea, but this really isn't my area of expertise so you'll
have to wait to see what Jan and Tim say.

> With regards to PV:
> Though XEN_DOMCTL_set_recipient works for both PV and HVM this patchset does 
> not
> bring PV kexec/kdump support. xc_domain_soft_reset() is limited to work with 
> HVM
> domains only. The main reason for that is: it is (in theory) possible to save 
> p2m
> and rebuild them with the new domain but that would only allow us to resume 
> execution
> from where we stopped. If we want to execute new kernel we need to build the 
> same
> kernel/initrd/bootstrap_pagetables/... structure we build to boot PV domain 
> initially.
> That however would destroy the original domain's memory thus making kdump 
> impossible.
> To make everything work additional support from kexec userspace/linux kernel 
> is
> required and I'm not sure it makes sense to implement all this stuff in the 
> light of
> PVH.

I'm fine with limiting this to HVM guests.

David


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


 


Rackspace

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