Nivedita Singhvi wrote: > What is the current state of mainline inclusion? > > Is there a set of tasks/patches/timetable that we can agree > to prior to KS/OLS? I'm hoping so..and when Rusty gets back Summarizing/quoting here for the community some conversation that took place off-list, from a related thread, so that the discussion can continue here... thanks, Nivedita --- Chris Wright wrote: > Here's my (intentionally simplified) take: > > 1) Xen > pros - supports Xen w/out requiring major changes > cons - doesn't support other projects directly, informal API (some > bits are pushed into shared data structures w/ no formal API) > > 2) VMI > pros - supports binary plug and play for the platform (native, > hypervisor du jour) > cons - the binary interface, requires an extra glue-layer that is > neither hv nor kernel, no users. > > 3) paravirt_ops > pros - can support multiple platforms, glue layer is part of kernel source > cons - no users and just an early prototype (so we need more API to > evaluate) > > Personally, I think the following makes good sense: > > 1) Get subarch stuff done, merge Xen > 2) Refine paravirt_ops, refactor Xen to use paravirt_ops, merge paravirt_ops > 3) Refine paravirt_ops, more focus on binary interface for both > optimisation and flexibility (moving more towards VMI). > > This is _not_ to discredit the VMI work at all. I think it's got some > quite useful and cool ideas. I think it's too soon to freeze the ABI, > and that we can evolve paravirt_ops towards something that looks vaguely > similar to VMI in a longer term, while making progress along the way. To which Rusty Russell responded: > I'll have to see your latest patches. I'd hope we're going to share > compile-time interfaces as much as reasonable. If we're too divergent, > I would disagree with merging Xen, since we'll just be whiplashing the > core code. If the core would remain mostly undisturbed, I would have no > real objection to this path. > > Could you consider one minor thing. I've been thinking it might be good > to have have CONFIG_PARAVIRT with child CONFIG_XEN. > > Later on, we add other children (CONFIG_VMI, CONFIG_NATIVE, etc). If > they choose multiple options, we use paravirt_ops rather than direct > calls. I don't know if this is overkill, but I do know that the hoops > Linux/Xen has to jump through to do cli w/SMP and PREEMPT are too large > to fit in any reasonable-size inline patch 8( And Chris came back with: >>> I'll have to see your latest patches. I'd hope we're going to share >>> compile-time interfaces as much as reasonable. If we're too divergent, >>> I would disagree with merging Xen, since we'll just be whiplashing the >>> core code. If the core would remain mostly undisturbed, I would have no >>> real objection to this path. > > > That's the core issue...defining the API. True, the paravirt_ops route > is slightly different from the subarch route in terms of source code > layout, and could result in excessive churn. From the POV of API, > they're encapsulating roughly the same requirements, so I do think > excessive churn is avoidable. > > >>> Could you consider one minor thing. I've been thinking it might be good >>> to have have CONFIG_PARAVIRT with child CONFIG_XEN. > > > The subarch method sort of does that naturally, introduce a new subarch > and its config and you're done. However, its shortcoming is mutually > exclusive config items w/out some dynamic way (VMI, paravirt_ops, or > similar) to update the subarch overrides. > > >>> Later on, we add other children (CONFIG_VMI, CONFIG_NATIVE, etc). If >>> they choose multiple options, we use paravirt_ops rather than direct >>> calls. I don't know if this is overkill, but I do know that the hoops >>> Linux/Xen has to jump through to do cli w/SMP and PREEMPT are too large >>> to fit in any reasonable-size inline patch 8( > > > Yeah, there was just some talk of disallowing PREEMPT and simplifying > that bit. But, I'd think we'd want to always use the paravirt_ops once > we have them. >
