From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: George.Dunlap@eu.citrix.com, tim@xen.org, keir.xen@gmail.com,
JBeulich@suse.com, xen-devel@lists.xenproject.org,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [V10 PATCH 0/4] pvh dom0 patches...
Date: Thu, 8 May 2014 15:29:02 -0700 [thread overview]
Message-ID: <20140508152902.5e09e17c@mantra.us.oracle.com> (raw)
In-Reply-To: <536B8378.6000703@citrix.com>
On Thu, 8 May 2014 14:15:36 +0100
David Vrabel <david.vrabel@citrix.com> wrote:
> On 08/05/14 01:12, Mukesh Rathor wrote:
> > On Wed, 7 May 2014 15:38:26 +0200
> > Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> >> On 07/05/14 15:20, Konrad Rzeszutek Wilk wrote:
> >>> For example, right now the Linux PV code can run with an E820 that
> >>> looks like swiss cheese - aka like the hosts' one. That is easily
> >>> seen if you boot an PV guest with PCI passthrough devices - as the
> >>> libxl 'e820_host' option gets turned on which creates an E820
> >>> that looks like the hosts. Granted it does not populate the P2M
> >>> as such (it is all linear). But the point is that the Linux
> >>> code is capable of dealing with this and bring the P2M to sync.
> >>>
> >>> Hoisting this up in the hypervisor would be a plus - as the
> >>> Linux code wouldn't have to do this anymore.
> >>
> >> IMHO doing it in the hypervisor is clearly the right solution,
> >> forcing the guest OS to do all this on it's own just promotes code
> >> duplication across the several OSes with PV(H) support.
> >
> > I am in agreement with you, but my point was code exists for PV
> > already, so if you address pvh only, then that code still has to
> > exist in the guest until PV reaches EOL.
> >
> > FWIW, my agreement with previous maintainers was to keep PVH as
> > close to PV as possible.
>
> PVH support in Linux should be in order of preference:
>
> 1. Like native.
> 2. Like HVM guests.
> 3. Like PV guests.
> 4. PVH specific.
I've been thinking:
PVH == PV guest in HVM container with HAP. (Actually, my initial
UP cut didn't require hap, but smp got very complicated. Besides
eliminating pv mmu became seondary goal).
Now, for prefrence (where choice exist):
For (each path)
if (HVM performs better)
pvh == hvm
else
pvh == pv
IOW, HVM good, PV better, PVH best! Altho, now i believe
hvm && pv == better
Historical background jfyi, when I talked about pvh to Keir, Ian P,
and can't remember others on the sidelines of xen summit years ago,
pv ops didn't exist, and my main motivation was performance. I didn't
think it would take this long, but I am euphoric to see it finally be
done, well, almost :)...
Mukesh
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-05-08 22:29 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 1:06 [V10 PATCH 0/4] pvh dom0 patches Mukesh Rathor
2014-04-30 1:06 ` [V10 PATCH 1/4] pvh dom0: construct_dom0 changes Mukesh Rathor
2014-05-06 15:18 ` Roger Pau Monné
2014-04-30 1:06 ` [V10 PATCH 2/4] pvh dom0: Add checks and restrictions for p2m_is_foreign Mukesh Rathor
2014-05-01 16:14 ` Tim Deegan
2014-04-30 1:06 ` [V10 PATCH 3/4] pvh dom0: Add and remove foreign pages Mukesh Rathor
2014-05-01 16:19 ` Tim Deegan
2014-05-02 1:45 ` Mukesh Rathor
2014-05-02 8:38 ` Jan Beulich
2014-05-02 8:55 ` Tim Deegan
2014-05-02 23:35 ` Mukesh Rathor
2014-05-05 7:46 ` Jan Beulich
2014-05-08 12:16 ` Tim Deegan
2014-05-08 13:25 ` Jan Beulich
2014-05-08 22:58 ` Mukesh Rathor
2014-04-30 1:06 ` [V10 PATCH 4/4] dom0: add opt_dom0pvh to setup.c Mukesh Rathor
2014-04-30 14:11 ` [V10 PATCH 0/4] pvh dom0 patches Roger Pau Monné
2014-04-30 18:12 ` Mukesh Rathor
2014-05-01 1:19 ` Mukesh Rathor
2014-05-02 11:05 ` Roger Pau Monné
2014-05-02 12:31 ` Jan Beulich
2014-05-02 14:06 ` Roger Pau Monné
2014-05-02 14:16 ` Jan Beulich
2014-05-02 14:35 ` Roger Pau Monné
2014-05-02 15:41 ` Jan Beulich
2014-05-02 16:13 ` Roger Pau Monné
2014-05-02 19:35 ` Konrad Rzeszutek Wilk
2014-05-03 0:01 ` Mukesh Rathor
2014-05-05 8:52 ` Roger Pau Monné
2014-05-06 0:28 ` Mukesh Rathor
2014-05-06 7:13 ` Roger Pau Monné
2014-05-06 8:09 ` Jan Beulich
2014-05-07 1:00 ` Mukesh Rathor
2014-05-07 7:50 ` Jan Beulich
2014-05-07 9:48 ` Roger Pau Monné
2014-05-07 11:34 ` Jan Beulich
2014-05-08 10:27 ` Roger Pau Monné
2014-05-08 10:44 ` Jan Beulich
2014-05-08 15:00 ` Roger Pau Monné
2014-05-08 15:20 ` Jan Beulich
2014-05-07 13:25 ` Konrad Rzeszutek Wilk
2014-05-08 0:04 ` Mukesh Rathor
2014-05-08 6:37 ` Jan Beulich
2014-05-08 19:15 ` Mukesh Rathor
2014-05-07 13:20 ` Konrad Rzeszutek Wilk
2014-05-07 13:38 ` Roger Pau Monné
2014-05-08 0:12 ` Mukesh Rathor
2014-05-08 10:52 ` George Dunlap
2014-05-08 13:15 ` David Vrabel
2014-05-08 22:29 ` Mukesh Rathor [this message]
2014-05-08 0:07 ` Mukesh Rathor
2014-05-06 19:38 ` Konrad Rzeszutek Wilk
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=20140508152902.5e09e17c@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=david.vrabel@citrix.com \
--cc=keir.xen@gmail.com \
--cc=roger.pau@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).