>>> On 03.05.17 at 13:38, <andrew.coop...@citrix.com> 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.coop...@citrix.com> 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@lists.xen.org
https://lists.xen.org/xen-devel

Reply via email to