[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |