[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 13:02, Jan Beulich wrote: >>>> 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? Nothing. I am unsure as to why do you think it does? The CONFIG_COMPAT infrastructure by HVM guests as well. > >> 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. I don't agree with this reasoning. If it is a reasonable configuration for common code to use, it is a reasonable configuration for x86 code to use. Or do you disagree with my argument for why it should be a configurable option which can be turned off in an x86 build? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |