Re: [PATCH 0/7] Various cleanup/fixes

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

 



On Wed, Oct 17, 2012 at 1:22 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
> On 17/10/12 17:53, Christoffer Dall wrote:
>> On Wed, Oct 17, 2012 at 12:09 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
>>> On 17/10/12 16:50, Christoffer Dall wrote:
>>>>>>>   ARM: KVM: move MMIO handling to its own files
>>>>>>
>>>>>> this one I'll look at later today.
>>>>>
>>>>> OK. Let me know what you think. I have a couple of other patches on the
>>>>> same theme.
>>>>>
>>>>
>>>> I will. Since the mmio handling is controversial, it's good that we
>>>> split that up.
>>>>
>>>> Unless the other patches are *necessary* for an upstream merge, I
>>>> think we should announce a code freeze and target an upstream merge
>>>> asap for everyone's benefit.
>>>
>>> Depending what you can necessary. A number of patches I've queued are
>>> related to moving accesses to HSR and friends into inline functions,
>>> making the code more readable - again, this could help the reviewers.
>>> They are mostly one-liners.
>>>
>>
>> necessary as in bugfixes or API stabilization.
>>
>> My whole point is that we can keep improving forever, but the more
>> cosmetics we change the more changes need to be reviewed.
>
> I agree on the stabilization. But my point here is not to introduce new
> features. Just to make the core mode easily reviewed. One of the
> complains I've heard so far is that the code is hard to read. Which is
> not surprising given that there's a lot of it, and that the problems it
> tackles are not simple.
>
> I'll post these patches as an RFC, and you're free to take them or not.
>

ok, thanks, I'll have a look.

>>>> It seems to me that we have a bug on restart to fix and
>>>
>>> Care to elaborate on this one?
>>>
>>
>> just fire up a guest and execute "reboot" in there and see the guest
>> kernel crash when it comes back up. If you can't reproduce, we should
>> talk more :)
>
> Interesting. It looks like the guest is taking a timer interrupt before
> being ready to handle it... Probably because the timer has been disabled
> while something is still pending. Investigating.
>

yeah, but a reset should mask interrupts, right? so I'm not sure,
anyway cool if you have cycles to look into it.

I'll be sending out a hugetlb patch real soon (I have one working
relying on the LPAE-only hugetlbfs patch from Catalin, but am working
on making it work on Will's series).

-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux