Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/05/17 08:27, Jan Beulich wrote:
>>>> On 03.05.17 at 20:29, <andrew.cooper3@xxxxxxxxxx> wrote:
>> Irrespective of the history which lead to this point, the important
>> question is whether we want to allow compiling x86 without CONFIG_COMPAT.
>>
>> If the eventual decision is yes, then new code should specifically be
>> introduced as being CONFIG_COMPAT-clean, because decisions like that
>> affect how to structure the code in the first place, and therefore be
>> far cleaner changes than trying to retrofit CONFIG_COMPAT in the future.
> Well, okay, I can agree with this. So what would an x86-Xen with
> COMPAT off support? 64-bit guests only, regardless of type?

Yes.  I intend this to mean 64bit guests of any type.

> As said before, I don't view it as a reasonable setup to allow only
> 64-bit HVM guests, so unless there is an intention to have a
> configuration where only PVH guests are supported (i.e. neither
> PV nor traditional HVM), I don't think allowing the option to be
> turned off makes sense on x86.

HVM and PVH aren't very different, but there will be a small amount of
work required to get plain HVM booting like this, because of hvmloader
currently being 32bit only.  I do see (potentially) value in allowing
64bit-only traditional HVM guests, e.g. with a 64bit OVMF firmware
(although this is already turning fairly PVH in nature).

PVH on the other hand is already capable of booting and running properly
were CONFIG_COMPAT to be disabled today.

The selection of CONFIG_PV, CONFIG_HVM and CONFIG_COMPAT will eventually
define the matrix of which guests are supported in this build of the
hypervisor, based on which chunks of functionality they compile out.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel