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

Re: [Minios-devel] [Xen-devel] [PATCH 1/2] mini-os: support keeping start_info structure conditionally

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".

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).

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.


Minios-devel mailing list



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