On Wed, Jul 13, 2016 at 02:19:55PM +0200, Petr Tesarik wrote:
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -95,6 +95,12 @@ int kexec_should_crash(struct task_struct *p)
> return 0;
> }
>
> +int kexec_crash_loaded(void)
> +{
> + return !!kexec_crash_image;
> +}
Nit: thi
On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
> On 09/11/15 21:30, Josh Triplett wrote:
> > On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
> >> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
> >> very old
On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
> On 09/11/15 16:10, Josh Triplett wrote:
> > On Fri, Sep 11, 2015 at 01:43:53PM +0200, Laszlo Ersek wrote:
> >> On 09/09/15 12:48, Laszlo Ersek wrote:
> >>> On 09/09/15 11:37, Ian Campbell wrote:
>
g/PlatformPei/Xen.c", and (I assume!) in the
> > host-side Xen tools as well.
> >
> > Personally I think that this dynamic approach is overkill (mainly
> > because I'm fine with being unable to install Debian Wheezy guests, both
> > wearing and not wearing my red fedora; and because the properties table
> > feature is not active for *any* OVMF guests anyway, in practice).
> >
> > So I'd like to ask you guys to decide which one you prefer: a simple
> > build time flag called NX_STACK_ENABLE (which will allow you to install
> > Wheezy guests, but deprive all other guests from a non-exec stack), or
> > the dynamic switches (which will take host-side work in Xen, plus a
> > matching OvmfPkg patch).
>
> I might go ahead and implement the -fw_cfg solution (for when OVMF runs
> on QEMU), leaving any parallel Xen functionality to Xen developers, for
> later.
>
> Because, I just found out that the GRUB binary built into the bits-2005
> release ISO <http://biosbits.org/download/> blows up the exact same way,
> and *that* is very annoying to me personally.
>
> Maybe we should invert the default. I'm not so convinced any longer that
> the current default is right. I didn't know that the GRUB version with
> code on the stack was this wide-spread.
Heh. Our fault for still using old (2.00) GRUB2, which we do plan to
upgrade at some point, though doing so doesn't top the TODO list. But I
do agree that with OVMF not having previously enforced NX in the UEFI
environment, going from that to immediately enforcing it *by default*
seems a bit quick. I would be surprised if doing so didn't break other
UEFI programs too.
Could OVMF build with NX support available, but disabled by default, so
that qemu can then turn it *on* with a -fw_cfg option?
Do any UEFI stacks on systems in the wild have NX turned on? I don't
think it makes sense for OVMF to enable NX by default until a majority
of new physical systems do so.
- Josh Triplett
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Tue, Dec 09, 2014 at 03:35:37PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> We'll be adding options for xen as well.
>
> Cc: Josh Triplett
> Cc: Borislav Petkov
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Michal Marek
&g
clarify kvmconfig is for kvm
> x86, arm, platform, xen, kconfig: add xen defconfig helper
For both:
Reviewed-by: Josh Triplett
> arch/x86/configs/xen.config | 6 ++
> kernel/configs/xen.config | 32
> scripts/kconfig/Makefile| 7 ++-
>
