[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |