[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

 


Rackspace

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