Hi Mark,
On Thu, Mar 23, 2017 at 06:54:52PM +, Mark Rutland wrote:
> Hi Daniel,
>
> On Thu, Mar 23, 2017 at 06:42:01PM +0100, Daniel Lezcano wrote:
> > In the next changes, we track the interrupts but we discard the timers as
> > that does not make sense. The next interrupt on a timer is
Hi Daniel,
On Thu, Mar 23, 2017 at 06:42:01PM +0100, Daniel Lezcano wrote:
> In the next changes, we track the interrupts but we discard the timers as
> that does not make sense. The next interrupt on a timer is predictable.
Sorry, but I could not parse this.
[...]
> diff --git
On Tue, Mar 21, 2017 at 04:47:05PM -0600, Tyler Baicar wrote:
> Currently external aborts are unsupported by the guest abort
> handling. Add handling for SEAs so that the host kernel reports
> SEAs which occur in the guest kernel.
>
> Signed-off-by: Tyler Baicar
> ---
>
On Tue, Mar 21, 2017 at 04:47:00PM -0600, Tyler Baicar wrote:
> ARM APEI extension proposal added SEA (Synchronous External Abort)
> notification type for ARMv8.
> Add a new GHES error source handling function for SEA. If an error
> source's notification type is SEA, then this function can be
In the next changes, we track the interrupts but we discard the timers as
that does not make sense. The next interrupt on a timer is predictable.
But, the API request_percpu_irq does not allow to pass a flag, hence specifying
if the interrupt type is a timer.
Solve this by passing a 'flags'
On Tue, Mar 21, 2017 at 04:46:59PM -0600, Tyler Baicar wrote:
> SEA exceptions are often caused by an uncorrected hardware
> error, and are handled when data abort and instruction abort
> exception classes have specific values for their Fault Status
> Code.
> When SEA occurs, before killing the
On Thu, Mar 23, 2017 at 03:16:49PM +, Marc Zyngier wrote:
> On 23/03/17 14:39, Christoffer Dall wrote:
> > On Thu, Mar 23, 2017 at 10:53:04AM +, Marc Zyngier wrote:
> >> On 22/03/17 17:27, Christoffer Dall wrote:
> >>>
> >>> I don't think there is a great use case beyond what we already
On 23/03/17 14:39, Christoffer Dall wrote:
> On Thu, Mar 23, 2017 at 10:53:04AM +, Marc Zyngier wrote:
>> On 22/03/17 17:27, Christoffer Dall wrote:
>>>
>>> I don't think there is a great use case beyond what we already do, it
>>> would just be to have one set of hyp vectors fewer, so that
Hi Dongjiu Geng,
On 23/03/17 13:01, Dongjiu Geng wrote:
> when the pfn is KVM_PFN_ERR_HWPOISON, it indicates to send
> SIGBUS signal from KVM's fault-handling code to qemu, qemu
> can handle this signal according to the fault address.
I'm afraid I beat you to it on this one:
On Thu, Mar 23, 2017 at 10:53:04AM +, Marc Zyngier wrote:
> On 22/03/17 17:27, Christoffer Dall wrote:
> > On Wed, Mar 22, 2017 at 04:14:44PM +, Marc Zyngier wrote:
> >> Hi Christoffer,
> >>
> >> On 22/03/17 13:37, Christoffer Dall wrote:
> >>> Hi Marc,
> >>>
> >>>
> >>> On Tue, Mar 21,
when the pfn is KVM_PFN_ERR_HWPOISON, it indicates to send
SIGBUS signal from KVM's fault-handling code to qemu, qemu
can handle this signal according to the fault address.
Signed-off-by: Dongjiu Geng
---
arch/arm/kvm/mmu.c | 20
On 21/03/17 19:20, Marc Zyngier wrote:
> At the moment, we only save/restore lr if on VHE, as we rely only
> the EL1 code to have preserved it in the non-VHE case.
>
> As we're about to get rid of the latter, let's move the save/restore
> code to the do_el2_call macro, unifying both code paths.
>
On 22/03/17 17:27, Christoffer Dall wrote:
> On Wed, Mar 22, 2017 at 04:14:44PM +, Marc Zyngier wrote:
>> Hi Christoffer,
>>
>> On 22/03/17 13:37, Christoffer Dall wrote:
>>> Hi Marc,
>>>
>>>
>>> On Tue, Mar 21, 2017 at 07:20:30PM +, Marc Zyngier wrote:
As noticed by RMK in this
13 matches
Mail list logo