[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 10:36, Jan Beulich wrote:
>>>> On 04.05.17 at 11:27, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 04/05/17 08:27, Jan Beulich wrote:
>>> 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).
> So that would then be yet another construct with no raw hardware
> equivalent. I'd prefer if we strove for improving our compatibility with
> raw hardware (as we do in various other places, you being one of
> the primary advocates to do so) instead of inventing new custom
> environments. Furthermore, while I can see the benefit of e.g. not
> allowing PV guests for security reasons, I'm having a hard time
> imagining some security benefit from disallowing a HVM guest to run
> in 32-bit mode. But perhaps you've thought of something already...

Hmm.  It might be nice to be able to compile out 32bit PV without
excluding 32bit HVM.

The security gain for COMPAT HVM guests is fractional, compared to PV,
but is non-zero; we have had infinite loops in the compat translation
code before.


Xen-devel mailing list



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