From: "H. Peter Anvin" <hpa@zytor.com>
To: Mike Rapoport <mike.rapoport@gmail.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Ramkumar Ramachandra <artagnon@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [QUERY] lguest64
Date: Wed, 31 Jul 2013 05:17:35 -0700 [thread overview]
Message-ID: <51F9005F.30501@zytor.com> (raw)
In-Reply-To: <CABpLfohrweJd0=0eFJDO7dv2HHxx_mbP0uySMDrsZZZXExdXug@mail.gmail.com>
On 07/31/2013 02:39 AM, Mike Rapoport wrote:
>
> The use case I had in mind is to use lguest as a nested hypervisor in
> public clouds. As of today, major public clouds do not support nested
> virtualization and it's not clear at all if they will expose this
> ability in their deployments. Addition of 64-bit support for lguest
> won't require changes to pvops and, as far as I can tell, won't change
> the number of pvops users...
>
"We can add a pvops user and that won't change the number of pvops
users" What?!
>> Yes, the subset of x86-64 machines for which there isn't hardware
>> virtualization support is pretty uninteresting.
>
> There are plenty virtual machines in EC2, Rackspace, HP and other
> clouds that do not have hardware virtualization. I believe that
> running a hypervisor on them may be pretty interesting.
The big problem with pvops is that they are a permanent tax on future
development -- a classic case of "the hooks problem." As such it is
important that there be a real, significant, use case with enough users
to make the pain worthwhile. With Xen looking at sunsetting PV support
with a long horizon, it might currently be possible to remove pvops some
time in the early 2020s or so timeframe. Introducing and promoting a
new user now would definitely make that impossible.
So it matters that the use case be real.
-hpa
next prev parent reply other threads:[~2013-07-31 12:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-19 9:06 [QUERY] lguest64 Ramkumar Ramachandra
2013-07-19 17:29 ` H. Peter Anvin
2013-07-19 17:42 ` Ramkumar Ramachandra
2013-07-19 18:46 ` H. Peter Anvin
2013-07-19 20:36 ` richard -rw- weinberger
2013-08-01 17:22 ` Ramkumar Ramachandra
2013-08-01 13:04 ` Alex Elsayed
2013-07-23 1:28 ` Rusty Russell
2013-07-31 9:39 ` Mike Rapoport
2013-07-31 12:17 ` H. Peter Anvin [this message]
2013-07-31 13:07 ` Mike Rapoport
2013-07-31 13:19 ` H. Peter Anvin
2013-07-31 14:32 ` Mike Rapoport
2013-08-01 2:12 ` Rusty Russell
2013-08-02 14:27 ` H. Peter Anvin
2013-07-31 13:17 ` Konrad Rzeszutek Wilk
2013-07-31 13:25 ` H. Peter Anvin
2013-08-02 19:09 ` Konrad Rzeszutek Wilk
2013-08-04 12:37 ` Gleb Natapov
2013-08-05 16:50 ` Konrad Rzeszutek Wilk
2013-08-05 16:59 ` H. Peter Anvin
2013-08-05 17:16 ` Konrad Rzeszutek Wilk
2013-07-31 15:31 ` Borislav Petkov
2013-08-01 7:18 ` Mike Rapoport
2013-08-08 19:15 ` Richard W.M. Jones
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=51F9005F.30501@zytor.com \
--to=hpa@zytor.com \
--cc=artagnon@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.rapoport@gmail.com \
--cc=rusty@rustcorp.com.au \
/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.