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

Re: [Xen-devel] [V11 PATCH 00/21]PVH xen: Phase I, Version 11 patches...



On Fri, 23 Aug 2013 13:05:08 +0100
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> >>> On 23.08.13 at 13:15, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
> >>> wrote:
> > On Fri, Aug 23, 2013 at 9:49 AM, Jan Beulich <JBeulich@xxxxxxxx>
> > wrote:
> >>>>> On 23.08.13 at 03:18, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> >>>>> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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