On 02/07/15 21:29, Chalamarla, Tirumalesh wrote: > is there a chance that this get merged in to 4.2? if not is it possible > to accept the other patches like adding implementations explicitly(like > Thunder). We first need to reach a conclusion on this. Until then, I don't plan to get anything in. As for 4.2, it feels way too late (the merge window is almost closed now). Thanks, M. > > Thanks, > Tirumalesh. >> On Jun 29, 2015, at 11:39 AM, Chalamarla, Tirumalesh >> <Tirumalesh.Chalamarla@xxxxxxxxxxxxxxxxxx >> <mailto:Tirumalesh.Chalamarla@xxxxxxxxxxxxxxxxxx>> wrote: >> >>> >>> On Jun 29, 2015, at 10:52 AM, Marc Zyngier <marc.zyngier@xxxxxxx >>> <mailto:marc.zyngier@xxxxxxx>> wrote: >>> >>> On 29/06/15 18:38, Peter Maydell wrote: >>>> On 29 June 2015 at 18:30, Marc Zyngier <marc.zyngier@xxxxxxx >>>> <mailto:marc.zyngier@xxxxxxx>> wrote: >>>>> On 29/06/15 18:13, Chalamarla, Tirumalesh wrote: >>>>>> Will this also prevents migrating between same implementations, >>>>>> if no how is this identified. >>>>> >>>>> This shouldn't. It is pretty easy to look at the incoming guest's MIDR, >>>>> and verify that it matches the default MIDR on the receiving >>>>> system. Any >>>>> difference, and the migration should abort. >>>> >>>> Do you really want to forbid migration between (say) >>>> Cortex-A57 r3p0 and Cortex-A57 r3p1 ? >>>> >>>> That seems pretty harsh. >>> >>> I think we may need to allow for some flexibility (same major version >>> only, or +/- 1 minor version...). The idea I'm trying to convey is that >>> with "generic CPI", migration is not guaranteed unless we're on >>> extremely similar hardware. >>> >> yes, this is the point i am trying to make, we need some flexibility. >> so that it works with same chips with different passes may be. >> if we are allowing this, then we are not putting emulation as a >> requirement. >> >> Thanks, >> Tirumalesh. >> >>> M. >>> -- >>> Jazz is not dead. It just smells funny... > -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
