From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [V11 PATCH 00/21]PVH xen: Phase I, Version 11 patches...
Date: Fri, 23 Aug 2013 17:40:09 -0700 [thread overview]
Message-ID: <20130823174009.0b418dc0@mantra.us.oracle.com> (raw)
In-Reply-To: <52176C1402000078000EDFCF@nat28.tlf.novell.com>
On Fri, 23 Aug 2013 13:05:08 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:
> >>> On 23.08.13 at 13:15, George Dunlap <George.Dunlap@eu.citrix.com>
> >>> wrote:
> > On Fri, Aug 23, 2013 at 9:49 AM, Jan Beulich <JBeulich@suse.com>
> > wrote:
> >>>>> On 23.08.13 at 03:18, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>>>> wrote:
> >>> Finally, I've the V11 set of patches.
> >>>
> >>> V11:
> >>> - gdt union patch not needed anymore, so dropped it.
> >>> - patch 17 made the last patch
> >>> - merged patch 22 and 23.
> >>
> >> So I'd be okay with applying 1...8 and 10...16, provided
> >> - you, Mukesh, can confirm that 9 can safely be left out,
> >> - you, George, don't object to that (considering your comments
> >> on v10).
> >
> > 1-8,10-16 I'm OK with the code for the most part, but the changesets
> > themselves leave something to be desired.
> >
> > Many of the prep patches would be fine, and the e820 struct relocate
> > is OK as well (though the changelog entry isn't really good).
> >
> > But the read_segment_register patch I think needs to be put in after
> > the is_pvh_*() patch, so the entire new bit of functionality comes
> > in one go. And the guest_kernel_mode() change should be a separate
> > patch, since it performs a similar function to
> > read_segment_register() -- i.e., enabling the emulated PV ops.
> >
> > In many cases, there are handfuls of other "!is_hvm" -> "is_pv"
> > scattered randomly throughout unrelated other changes. And some of
> > the changes from patches 15-16 I think should be grouped together
> > with later changesets (e.g., all the irq-related ones in a single
> > changeset).
> >
> > Also, I think that having a separate set of nearly-identical exit
> > handlers for PVH is a really bad idea. Without them, however, pvh.c
> > is only a single small function long -- so I think we shouldn't
> > bother with pvh.c, and should just put that function into vmx.c.
> >
> > All in all, I would personally prefer if you hold off until my
> > series re-work; I should have something by the end of next week.
> >
> > My basic outline for the re-worked patch series looks like the
> > following (NOT one patch per bullet):
> > - Prep patches
> > - Introduce pvh domain type
> > - Disable unused HVM functionality
> > - Enable used PV functionality
> >
> > What do you think?
>
> Fine with me, but perhaps Mukesh won't be that happy...
It's OK. I'd like this to be merged in asap so I and others can working
on the FIXME's right away...
thanks
mukesh
next prev parent reply other threads:[~2013-08-24 0:40 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-23 1:18 [V11 PATCH 00/21]PVH xen: Phase I, Version 11 patches Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 01/21] PVH xen: Add readme docs/misc/pvh-readme.txt Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 02/21] PVH xen: add params to read_segment_register Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 03/21] PVH xen: Move e820 fields out of pv_domain struct Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 04/21] PVH xen: hvm related preparatory changes for PVH Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 05/21] PVH xen: vmx " Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 06/21] PVH xen: vmcs " Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 07/21] PVH xen: Introduce PVH guest type and some basic changes Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 08/21] PVH xen: introduce pvh_vcpu_boot_set_info() and vmx_pvh_vcpu_boot_set_info() Mukesh Rathor
2013-08-23 1:18 ` [V11 PATCH 09/21] PVH xen: domain create, context switch related code changes Mukesh Rathor
2013-08-23 8:12 ` Jan Beulich
2013-08-23 1:18 ` [V11 PATCH 10/21] PVH xen: support invalid op emulation for PVH Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 11/21] PVH xen: Support privileged " Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 12/21] PVH xen: interrupt/event-channel delivery to PVH Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 13/21] PVH xen: additional changes to support PVH guest creation and execution Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 14/21] PVH xen: mapcache and show registers Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 15/21] PVH xen: mtrr, tsc, timers, grant changes Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 16/21] PVH xen: add hypercall support for PVH Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 17/21] PVH xen: vmcs related changes Mukesh Rathor
2013-08-23 8:41 ` Jan Beulich
2013-08-24 0:26 ` Mukesh Rathor
2013-08-26 8:15 ` Jan Beulich
2013-08-27 17:00 ` George Dunlap
2013-08-27 22:43 ` Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 18/21] PVH xen: HVM support of PVH guest creation/destruction Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 19/21] PVH xen: VMX " Mukesh Rathor
2013-08-23 9:14 ` Jan Beulich
2013-08-24 0:27 ` Mukesh Rathor
2013-08-23 1:19 ` [V11 PATCH 20/21] PVH xen: introduce vmexit handler for PVH Mukesh Rathor
2013-08-23 9:12 ` Jan Beulich
2013-08-24 0:35 ` Mukesh Rathor
2013-08-26 8:22 ` Jan Beulich
2013-08-23 1:19 ` [V11 PATCH 21/21] PVH xen: Checks, asserts, and limitations " Mukesh Rathor
2013-08-23 8:49 ` [V11 PATCH 00/21]PVH xen: Phase I, Version 11 patches Jan Beulich
2013-08-23 11:15 ` George Dunlap
2013-08-23 12:05 ` Jan Beulich
2013-08-24 0:40 ` Mukesh Rathor [this message]
2013-08-27 17:05 ` George Dunlap
2013-08-27 19:18 ` Mukesh Rathor
2013-08-28 11:20 ` George Dunlap
2013-08-29 0:16 ` Mukesh Rathor
2013-08-28 0:37 ` Mukesh Rathor
2013-08-29 16:28 ` George Dunlap
2013-08-30 0:25 ` Mukesh Rathor
2013-08-30 11:02 ` George Dunlap
2013-08-30 17:21 ` George Dunlap
2013-08-30 21:22 ` Mukesh Rathor
2013-09-02 14:52 ` George Dunlap
2013-09-06 1:07 ` Mukesh Rathor
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=20130823174009.0b418dc0@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--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).