On 29/08/2016 13:28, Juergen Gross wrote: > On 29/08/16 13:47, Andrew Cooper wrote: >> On 29/08/2016 12:17, Juergen Gross wrote: >>> On 29/08/16 13:09, Wei Liu wrote: >>>> On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote: >>>>> grub stubdom needs the start_info structure. Keep a copy of it in >>>>> pv mini-os if configured via "CONFIG_KEEP_STARTINFO". This should >>>>> default to "n" in order to have it enabled only when really needed. >>>>> >>>> I'm not sure I understand the rationale for this. >>>> >>>> Shouldn't start_info always be kept when mini-os is PV? Under what >>>> condition should it not be kept? >>> The application on top of Mini-OS shouldn't depend on Mini-OS being >>> paravirtualized or not in the "normal" case. grub-stubdom is a >>> special case, as it needs to kexec to a loaded kernel which in turn >>> needs the start_info, of course. >>> >>> ioemu-stubdom OTOH should not need start_info as it could work on >>> a HVMlite Mini-OS, too. >>> >>> The idea of removing start_info in my HVMlite series was driven by >>> that thought: any application using start_info should break as it >>> clearly wouldn't be agnostic of the mode (pv or HVMlite) of Mini-OS. >>> pv-grub was an oversight here. >>> >>> I'm planning to modify ioemu-stubdom in the future to not use >>> start_info and then let it run in HVMlite mode, too. >> There is an issue here between MiniOS itself, and "the stubdom application". > Correct. > >> There should be no circumstance where the stubdom application needs >> access (pv-grub being a special case, but maybe the kexec details can be >> hidden as well). > Indeed. I'll have a look if this is possible. In case I find a clean > solution I'll send patches including one removing CONFIG_KEEP_STARTINFO > again. > >> However, while there is still relevant information in start_info, the >> low level PV bits should still have access. Moreover, it is necessary >> to always have access when doing suspend/resume. > The information from start_info is available inside Mini-OS. So this > should be no problem.
I have never understood MiniOS's decision to memcpy() it elsewhere. It is just a plain page of RAM set up by the domain builder; copying it elsewhere is just a waste of space. OTOH, you must pass a pointer to it in the suspend() hypercall, so the resume logic can re-modify part of it. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
