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.chalama...@caviumnetworks.com
>> <mailto:tirumalesh.chalama...@caviumnetworks.com>> wrote:
>>
>>>
>>> On Jun 29, 2015, at 10:52 AM, Marc Zyngier <marc.zyng...@arm.com
>>> <mailto:marc.zyng...@arm.com>> wrote:
>>>
>>> On 29/06/15 18:38, Peter Maydell wrote:
>>>> On 29 June 2015 at 18:30, Marc Zyngier <marc.zyng...@arm.com
>>>> <mailto:marc.zyng...@arm.com>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
