[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 0/9] toolstack-based approach to pvhvm guest kexec
On Thu, Dec 04, 2014 at 03:46:59PM +0100, Vitaly Kuznetsov wrote: > Wei Liu <wei.liu2@xxxxxxxxxx> writes: > > > On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote: > >> Changes from RFCv3: > >> This is the first non-RFC series as no major concerns were expressed. I'm > >> trying > >> to address Jan's comments. Changes are: > >> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really > >> like > >> the name but nothing more appropriate came to my mind) which incorporates > >> former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent > >> original domain from changing its allocations during transfer procedure. > >> - Check in free_domheap_pages() that assign_pages() succeeded. > >> - Change printk() in free_domheap_pages(). > >> - DOMDYING_locked state was introduced to support XEN_DOMCTL_devour. > >> - xc_domain_soft_reset() got simplified a bit. Now we just wait for the > >> original > >> domain to die or loose all its pages. > >> - rebased on top of current master branch. > >> > >> 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 > >> > >> 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. > >> > > > > What would happen if you soft reset a PV guest? At the very least soft > > reset should be explicitly forbidden in PV case. > > Well, nothing particulary bad from hypervisor point of view > happens. But when PV guest dies page tables are being destroyed (and we > lose the knowledge anyway). It would be possible for the toolstack to > start from the beggining - build bootstrap tables, put kernel/initrd and > start everything. I however don't see any value in doing so: our memory > gets destroyed and it is going to be the same as plain reboot. > OK. As long as hypervisor is safe I'm OK with it. I was thinking from a security PoV, i.e. there is no guest triggerable crash of hypervisor, guest cannot escape by providing arbitrary new kernel, etc. > Why do we need to forbid the call for PV? (xc_domain_soft_reset() > already forbids PV). > > > > >> Original description: > >> > >> When a PVHVM linux guest performs kexec there are lots of things which > >> require taking care of: > >> - shared info, vcpu_info > >> - grants > >> - event channels > >> - ... > > > > Is there a complete list? > > > > Konrad tried to assemble it here: > http://lists.xen.org/archives/html/xen-devel/2014-06/msg03889.html > > > >> Instead of taking care of all these things we can rebuild the domain > >> performing kexec from scratch doing so-called soft-reboot. > >> > >> The idea was suggested by David Vrabel, Jan Beulich, and Konrad Rzeszutek > >> Wilk. > >> > > > > As this approach requires toolstack do complex interaction with > > hypervisor and preserve / throw away a bunch of states. I think the > > whole procedure should be documented. > > Sure.. Where would you expect such doc to appear? > I think libxl_internal.h is the right place. Just group the documentation with other internal functions you introduced. Re all the links, thanks, I will have a look. Wei. > > > > It would also be helpful if you link to previous discussions in your > > cover letter. > > Sure, will do next time. For now: > on resetting VCPU_info (and that's where 'rebuild everything with the > toolstack solution' was suggested): > http://lists.xen.org/archives/html/xen-devel/2014-08/msg01869.html > Previous versions: > http://lists.xen.org/archives/html/xen-devel/2014-08/msg01630.html > http://lists.xen.org/archives/html/xen-devel/2014-08/msg00603.html > > EVTCHNOP_reset (got merged): > http://lists.xen.org/archives/html/xen-devel/2014-07/msg03979.html > Previous: > http://lists.xen.org/archives/html/xen-devel/2014-07/msg03925.html > http://lists.xen.org/archives/html/xen-devel/2014-07/msg03322.html > http://lists.xen.org/archives/html/xen-devel/2014-07/msg02500.html > > This patch series: > http://lists.xen.org/archives/html/xen-devel/2014-10/msg00764.html > http://lists.xen.org/archives/html/xen-devel/2014-09/msg03623.html > http://lists.xen.org/archives/html/xen-devel/2014-08/msg02309.html > > > > > Wei. > > -- > Vitaly _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |