[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 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.


Xen-devel mailing list



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