From: boris ostrovsky <boris.ostrovsky@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: keir@xen.org, "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Tim Deegan" <tim@xen.org>,
xen-devel@lists.xen.org, jbeulich@suse.com,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps
Date: Wed, 28 May 2014 14:18:54 -0400 [thread overview]
Message-ID: <5386288E.6060104@oracle.com> (raw)
In-Reply-To: <1401270157.24800.12.camel@kazak.uk.xensource.com>
On 5/28/2014 5:42 AM, Ian Campbell wrote:
> On Fri, 2014-05-23 at 11:53 -0400, Boris Ostrovsky wrote:
>> On 05/23/2014 11:35 AM, Roger Pau Monné wrote:
>>> On 23/05/14 17:32, Boris Ostrovsky wrote:
>>>> On 05/23/2014 11:20 AM, Andrew Cooper 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@oracle.com>
>>>>>>>> ---
>>>>>>>> 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.
>>>>>>
>>>>>> -boris
>>>>> 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.
>>>> Yes, that's true.
>>>>
>>>> The problem that we have now is that if we have 'pvh=1' in the config
>>>> file the guest will fail to start if PVH is not on. Can we, for example,
>>>> revert (with a warning) to pure PV if that's the case?
>>> Won't this option go away once PVH is stable, so the toolstack can
>>> detect if the kernel supports PVH and start the guest in this mode by
>>> default? (of course falling back to PV if PVH is not supported).
>> Yes, it will, by virtue of hypervisor never having to take this action
>> (reverting to PV) since PVH would be stable and always supported.
> This ignores hardware which cannot support pvh and guest kernels which
> are lacking the support for it.
>
>> I just don't know whether ignoring pvh=1 directive on systems where PVH
>> is not supported is acceptable. (Your "of course" seems to indicate that
>> you think it is.)
> The ideal case would be that you don't say pvh=anything and the
> toolstack will automatically use pvh if the h/w and kernel both support
> it, otherwise it will use pv.
But don't we want to let the user now whether PVH is supported? Could it
be that they may only want to start a guest in PVH mode? (I realize that
I am contradicting my own suggestion to ignore pvh=1).
-boris
>
> If you say pvh=1 then the toolstack should unconditionally attempt to
> create a pvh guest, and if the hypervisor rejects an attempt to create
> such a domain then it should fail, because this is what you have asked
> for with pvh=1.
Then we need some sort of indication of PVH is support so that users
know whether they can supply pvh=1.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-05-28 18:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 14:55 [PATCH] x86: Expose hypervisor's PVH support via xen_caps Boris Ostrovsky
2014-05-23 15:00 ` Andrew Cooper
2014-05-23 15:08 ` Boris Ostrovsky
2014-05-23 15:20 ` Andrew Cooper
2014-05-23 15:32 ` Boris Ostrovsky
2014-05-23 15:35 ` Roger Pau Monné
2014-05-23 15:53 ` Boris Ostrovsky
2014-05-28 9:42 ` Ian Campbell
2014-05-28 18:18 ` boris ostrovsky [this message]
2014-05-28 21:12 ` Mukesh Rathor
2014-05-26 9:33 ` Jan Beulich
2014-05-27 3:03 ` Boris Ostrovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5386288E.6060104@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=roger.pau@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.