qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/17] ppc: preparing pnv landing


From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/17] ppc: preparing pnv landing
Date: Thu, 17 Mar 2016 15:28:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0

On 03/17/2016 03:45 AM, David Gibson wrote:
> On Wed, Mar 16, 2016 at 10:08:19AM +0100, Cédric Le Goater wrote:
>> On 03/16/2016 02:19 AM, David Gibson wrote:
>>> On Tue, Mar 15, 2016 at 09:11:31AM +0100, Cédric Le Goater wrote:
>>>> On 03/15/2016 01:39 AM, David Gibson wrote:
>>>>> On Mon, Mar 14, 2016 at 05:56:23PM +0100, Cédric Le Goater wrote:
>>>>>> Hello,
>>>>>>
>>>>>> This is a first mini-serie of patches adding support for new ppc SPRs.
>>>>>> They were taken from Ben's larger patchset adding the ppc powernv
>>>>>> platform and they should already be useful for the pseries guest
>>>>>> migration.
>>>>>>
>>>>>> Initial patches come from :
>>>>>>
>>>>>>  https://github.com/ozbenh/qemu/commits/powernv
>>>>>>
>>>>>> The changes are mostly due to the rebase on Dave's 2.6 branch:
>>>>>>
>>>>>>  https://github.com/dgibson/qemu/commits/ppc-for-2.6
>>>>>>
>>>>>> A couple more are bisect and checkpatch fixes and finally some patches
>>>>>> were merge to reduce the noise.
>>>>>>
>>>>>>       
>>>>>>
>>>>>> The patchset is also available here: 
>>>>>>
>>>>>>  https://github.com/legoater/qemu/commits/for-2.6
>>>>>>
>>>>>> It was quickly tested with a pseries guest using KVM and TCG.
>>>>>
>>>>> Hmm.. do these all fix bugs with migration, or only some of them?
>>>>
>>>> Probably only some. 
>>>>
>>>> Initially, Thomas gave a shorter list which I expanded to a larger one 
>>>> because of dependencies between patches and I didn't want to change too
>>>> much what Ben had sent. You had also reviewed a few.
>>>>
>>>>> The relevance is that things to fix migration should go into 2.6, but
>>>>> preparation work for powernv that doesn't fix bug shouldn't really be
>>>>> going in now, after the soft freeze and will need to wait for 2.7.
>>>>
>>>> OK. I will rework and keep the rest for 2.7. 
>>>
>>> So, I'm ok with including (low risk) patches that aren't directly
>>> relevant to 2.6 if they're prereqs for patches that are relevant to
>>> 2.6.  After all, reworking the patches isn't risk free either.  Please
>>> mention why these patches are being included in the commit messages
>>> though.
>>
>> Sure.  
>>
>>>> Thomas, thanks for the review. I have identified a few things I need 
>>>> to work on but may be, the patchset is still too large for 2.6 ?
>>>
>>> It's not really a question of being too large, it's that I'm nervous
>>> about applying patches which touch the core translation code
>>> (e.g. fixes to HV mode tests) during soft freeze if they're not
>>> addressing a bug that's relevant to 2.6.
>>
>> Could you please take a look at these two patches to see if they are 
>> relevant for 2.6 ? From my readings, they seem to be the only ones on 
>> the edge.
>>
>>      06/17  ppc: Create cpu_ppc_set_papr() helper 
>>      11/17  ppc: Initialize AMOR in PAPR mode  
> 
> Ok, I've replied to each of those.
> 
>> but it makes sense to take them if we take :
>>
>>      12/17  ppc: Fix writing to AMR/UAMOR (move hunk to 13)
> 
> I'm not seeing a lot of cause to put this in for 2.6.  The registers
> in question are already linked up to KVM, so migration should be ok,
> and I don't believe we have real use cases which are hitting the bugs
> this patch fixes.  Except...
> 
>>      13/17  ppc: Add POWER8 IAMR register (rework hunk)
> 
> ..that I guess it's kind of a pre-req for this one, which could fix real
> migration bugs.

Yes. So, I will send a v3 removing the LPCR changes in the cpu_ppc_set_papr()
helper. How does that sound ? 

Thanks,

C.

 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]