[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C
>>> On 03.05.17 at 13:38, <andrew.cooper3@xxxxxxxxxx> wrote: > On 03/05/17 12:26, Wei Liu wrote: >> On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: >>>>>> On 02.05.17 at 20:05, <andrew.cooper3@xxxxxxxxxx> wrote: >>>> --- /dev/null >>>> +++ b/xen/arch/x86/pv/traps.c >>>> @@ -0,0 +1,44 @@ >>>> > +/*************************************************************************** > *** >>>> + * arch/x86/pv/traps.c >>>> + * >>>> + * PV low level entry points. >>>> + * >>>> + * This program is free software; you can redistribute it and/or modify >>>> + * it under the terms of the GNU General Public License as published by >>>> + * the Free Software Foundation; either version 2 of the License, or >>>> + * (at your option) any later version. >>>> + * >>>> + * This program is distributed in the hope that it will be useful, >>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>> + * GNU General Public License for more details. >>>> + * >>>> + * You should have received a copy of the GNU General Public License >>>> + * along with this program; If not, see <http://www.gnu.org/licenses/>. >>>> + * >>>> + * Copyright (c) 2017 Citrix Systems Ltd. >>>> + */ >>>> + >>>> +#include <xen/hypercall.h> >>>> + >>>> +#include <asm/apic.h> >>>> + >>>> +#ifdef CONFIG_COMPAT >>> As expressed before, I disagree to the re-introduction of such >>> conditionals in x86 code. >>> >> I'm curious to know how the COMPAT interface is treated long term. >> >> I guess you're of the opinion that we should always have them enabled? > > There is a valid usecase to disable CONFIG_COMPAT, seeing as sufficient > PVH interfaces exist to start APs straight in 64bit mode, as it provides > a meaningful reduction in hypervisor attack surface. What does PVH have to do with 32-bit PV compat guest support? > As it is a configurable option, I intend to work in a direction which > eventually makes it usable under x86. > > If there is a wish to move in an opposite direction, that should be a > separate discussion made over a patch removing its entry from > common/Kconfig. Once again - from common code perspective this is a valid config option to have. X86, however, unconditionally selects it, so there's no point having such conditionals in x86 code. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |