[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: Expose hypervisor's PVH support via xen_caps

On 05/26/2014 05:33 AM, Jan Beulich wrote:
On 23.05.14 at 17:20, <andrew.cooper3@xxxxxxxxxx> wrote:
On 23/05/14 16:08, Boris Ostrovsky wrote:
On 05/23/2014 11:00 AM, Andrew Cooper wrote:
On 23/05/14 15:55, Boris Ostrovsky wrote:
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
   xen/arch/x86/setup.c | 5 +++++
   1 file changed, 5 insertions(+)
If the plan is to try and PVH and HVM back into one mode as far as Xen
is concerned, doesn't this become redundant?
Yes, I was thinking about this but we currently don't have (or,
rather, I can't think of) a good way to determine whether we can start
a PVH guest. We can grep the log but that doesn't feel like a
particularly good solution.

One option could be to postpone this patch until 4.5 freezes and see
whether we indeed followed up on the plan and if we didn't then
integrate it.
I don't see what 4.5 has to do with this - 4.4 already has PVH
support (it being experimental and DomU only imo doesn't matter
as far as feature reporting is concerned).

My concern here is that if this patch gets accepted, it will have to say
forever more as the cap strings are a very public API.
Depends how you view it - if this becomes indistinguishable from
PVH for the tools stack, it could also get dropped again. Otoh I
don't think it will (or even should) become indistinguishable, and
hence I'm not sure its functional folding with (most of) HVM would
actually be a valid reason to drop this indication again (or, if it
has to remain, to consider it deprecated and pointless).

Currently PVH requires, for example, VMX's secondary exec controls. I don't know whether the plan is to drop this requirement eventually but if not then some processors might not be able to run PVH.


Xen-devel mailing list



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