Re: [Xen-devel] PVH cleanups after 4.5

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/12/14 09:54, Ian Campbell wrote:
> On Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
>> At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
>>>>>> On 04.12.14 at 18:25, <tim@xxxxxxx> wrote:
>>>> Potential feature flags, based on whiteboard notes at the session.
>>>> Things that are 'Yes' in both columns might not need actual flags :)
>>>>
>>>>                      'HVM'       'PVH'
>>>> 64bit hypercalls      Yes         Yes
>>>> 32bit hypercalls      Yes         No
>>> Iiuc the lack of support of 32-bit hypercalls is simply because PVH
>>> guests aren't expected to use them as being always 64-bit right
>>> now. I.e. I can't really see why we couldn't just enable them once
>>> the 64-bit hypercall tables got combined, in which case we wouldn't
>>> need a feature flag here either.
>> Agreed -- I think the same will apply to a few other things, like shadow
>> pagetables and some of the other MM tricks.  
> Might we want to constrain a given PVH domain to only make 32- or 64-bit
> hypercalls?
>
> Or do we consider already having crossed that bridge with HVM enough
> reason to allow it for PVH? I'm wonder if that, even if it is
> technically possible to support not, doing so might mitigate some
> potential security issues down the line. There's obviously a tradeoff
> against in-guest flexibility though.

Madating a 32/64bit split serves only to cause booting issues; you need
to know a-priori what the eventual kernel is going to be before you
build the domain. This is an awkward issue with PV domains which
*really* wants not to apply to PVH as well.

PVH guests with the plan of "HVM - qemu" should be able to fully choose
their operating mode, and allow for in-guest bootstrapping which is far
superior from a security/isolation point of view than toolstack
bootstrapping.

~Andrew


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