On 23 June 2016 at 22:33, Peter Maydell wrote:
> On 23 June 2016 at 21:03, Ard Biesheuvel wrote:
>> UEFI is guaranteed to leave
>> the GIC in a usable state for the OS if it runs from the same
>> exception level
>
> For a
On 23 June 2016 at 21:03, Ard Biesheuvel wrote:
> UEFI is guaranteed to leave
> the GIC in a usable state for the OS if it runs from the same
> exception level
For a no-security-extensions system, leaving the interrupts
in Group 0 is still "a usable state for the OS",
On 23 June 2016 at 16:52, Laszlo Ersek wrote:
> On 06/23/16 16:18, Ed Maste wrote:
>> On 23 June 2016 at 07:36, Laszlo Ersek wrote:
>>> On 06/22/16 22:53, Peter Maydell wrote:
On 22 June 2016 at 19:09, Ed Maste wrote:
> On 15
On 06/23/16 16:18, Ed Maste wrote:
> On 23 June 2016 at 07:36, Laszlo Ersek wrote:
>> On 06/22/16 22:53, Peter Maydell wrote:
>>> On 22 June 2016 at 19:09, Ed Maste wrote:
On 15 June 2016 at 06:10, Peter Maydell wrote:
>
On 23 June 2016 at 07:36, Laszlo Ersek wrote:
> On 06/22/16 22:53, Peter Maydell wrote:
>> On 22 June 2016 at 19:09, Ed Maste wrote:
>>> On 15 June 2016 at 06:10, Peter Maydell wrote:
A quick scan through
On Thu, Jun 23, 2016 at 01:36:40PM +0200, Laszlo Ersek wrote:
> On 06/22/16 22:53, Peter Maydell wrote:
> > On 22 June 2016 at 19:09, Ed Maste wrote:
> >> On 15 June 2016 at 06:10, Peter Maydell wrote:
> >>>
> >>> A quick scan through
On 06/22/16 22:53, Peter Maydell wrote:
> On 22 June 2016 at 19:09, Ed Maste wrote:
>> On 15 June 2016 at 06:10, Peter Maydell wrote:
>>>
>>> A quick scan through http://fxr.watson.org/fxr/source/arm64/arm64/gic_v3.c
>>> doesn't seem to show it
On 2016/6/23 5:45, Ed Maste wrote:
> On 22 June 2016 at 16:53, Peter Maydell wrote:
>>
>> Yeah, it looks like the same bug is also present in UEFI itself
>> (it's super popular!). Laszlo, Ard, do you have a prebuilt
>> UEFI binary with Ard's fix?
>>
>> Probably you'll
On 22 June 2016 at 22:45, Ed Maste wrote:
> On 22 June 2016 at 16:53, Peter Maydell wrote:
>>
>> Yeah, it looks like the same bug is also present in UEFI itself
>> (it's super popular!). Laszlo, Ard, do you have a prebuilt
>> UEFI binary with Ard's
On 22 June 2016 at 16:53, Peter Maydell wrote:
>
> Yeah, it looks like the same bug is also present in UEFI itself
> (it's super popular!). Laszlo, Ard, do you have a prebuilt
> UEFI binary with Ard's fix?
>
> Probably you'll find that if UEFI is configuring the GIC
On 22 June 2016 at 19:09, Ed Maste wrote:
> On 15 June 2016 at 06:10, Peter Maydell wrote:
>>
>> A quick scan through http://fxr.watson.org/fxr/source/arm64/arm64/gic_v3.c
>> doesn't seem to show it setting the IGROUPR registers anywhere,
>> so it
On 15 June 2016 at 06:10, Peter Maydell wrote:
>
> A quick scan through http://fxr.watson.org/fxr/source/arm64/arm64/gic_v3.c
> doesn't seem to show it setting the IGROUPR registers anywhere,
> so it probably is a guest bug. (You can use "-d 'trace:gicv3*'" to
> enable
On 06/22/16 11:09, Andrew Jones wrote:
> On Wed, Jun 22, 2016 at 04:27:35PM +0800, Shannon Zhao wrote:
>>
>>
>> On 2016/6/22 15:43, Andrew Jones wrote:
>>> On Wed, Jun 22, 2016 at 09:42:29AM +0800, Shannon Zhao wrote:
>
>
> On 2016/6/22 3:53, Peter Maydell wrote:
>>> On 21 June
On Wed, Jun 22, 2016 at 04:27:35PM +0800, Shannon Zhao wrote:
>
>
> On 2016/6/22 15:43, Andrew Jones wrote:
> > On Wed, Jun 22, 2016 at 09:42:29AM +0800, Shannon Zhao wrote:
> >> >
> >> >
> >> > On 2016/6/22 3:53, Peter Maydell wrote:
> >>> > > On 21 June 2016 at 20:45, Laszlo Ersek
On 2016/6/22 15:43, Andrew Jones wrote:
> On Wed, Jun 22, 2016 at 09:42:29AM +0800, Shannon Zhao wrote:
>> >
>> >
>> > On 2016/6/22 3:53, Peter Maydell wrote:
>>> > > On 21 June 2016 at 20:45, Laszlo Ersek wrote:
> > >> > On 06/21/16 19:21, Peter Maydell wrote:
>>>
On Wed, Jun 22, 2016 at 09:42:29AM +0800, Shannon Zhao wrote:
>
>
> On 2016/6/22 3:53, Peter Maydell wrote:
> > On 21 June 2016 at 20:45, Laszlo Ersek wrote:
> >> > On 06/21/16 19:21, Peter Maydell wrote:
> >>> >> and add a note I forgot to mention: my primary hypothesis is
On 2016/6/22 3:53, Peter Maydell wrote:
> On 21 June 2016 at 20:45, Laszlo Ersek wrote:
>> > On 06/21/16 19:21, Peter Maydell wrote:
>>> >> and add a note I forgot to mention: my primary hypothesis is that
>>> >> the problem here is "guest does not write to the GICD_IGROUPR
On 21 June 2016 at 20:45, Laszlo Ersek wrote:
> On 06/21/16 19:21, Peter Maydell wrote:
>> and add a note I forgot to mention: my primary hypothesis is that
>> the problem here is "guest does not write to the GICD_IGROUPR and
>> GICR_IGROUPR registers to program the interrupts
On 06/21/16 19:21, Peter Maydell wrote:
> On 21 June 2016 at 18:18, Andrew Jones wrote:
>>
>> Why oh why does mutt ask me who to CC after composing the mail instead
>> of before (after is when I've forgotten...) Maybe there's some config
>> I can change. OK, this time with Ard
On Tue, Jun 21, 2016 at 05:12:02PM +0200, Andrew Jones wrote:
> On Tue, Jun 21, 2016 at 03:55:46PM +0100, Peter Maydell wrote:
> > On 21 June 2016 at 15:45, Andrew Jones wrote:
> > > On Wed, Jun 15, 2016 at 04:53:35PM +0800, Shannon Zhao wrote:
> > >> I have another test with
Why oh why does mutt ask me who to CC after composing the mail instead
of before (after is when I've forgotten...) Maybe there's some config
I can change. OK, this time with Ard really on CC.
On Tue, Jun 21, 2016 at 07:15:57PM +0200, Andrew Jones wrote:
> On Tue, Jun 21, 2016 at 05:12:02PM
On 21 June 2016 at 18:18, Andrew Jones wrote:
>
> Why oh why does mutt ask me who to CC after composing the mail instead
> of before (after is when I've forgotten...) Maybe there's some config
> I can change. OK, this time with Ard really on CC.
Heh. Let me repeat my other
On 21 June 2016 at 18:15, Andrew Jones wrote:
> Laszlo asked me to reply again, this time with Ard on CC, and with
> some more details.
>
> Issue:
> AAVMF boot under gicv3 emulation, e.g.
> -machine virt,accel=tcg,gic-version=3
>
> fails with the above message. gicv3
On Tue, Jun 21, 2016 at 03:55:46PM +0100, Peter Maydell wrote:
> On 21 June 2016 at 15:45, Andrew Jones wrote:
> > On Wed, Jun 15, 2016 at 04:53:35PM +0800, Shannon Zhao wrote:
> >> I have another test with a freebsd guest. When I specify gic-version=3
> >> at the QEMU command
On 21 June 2016 at 15:45, Andrew Jones wrote:
> On Wed, Jun 15, 2016 at 04:53:35PM +0800, Shannon Zhao wrote:
>> I have another test with a freebsd guest. When I specify gic-version=3
>> at the QEMU command line, the guest can't start. But with gic-version=2
>> it's fine. And
On Wed, Jun 15, 2016 at 04:53:35PM +0800, Shannon Zhao wrote:
>
>
> On 2016/6/14 22:38, Peter Maydell wrote:
> > This series implements emulation of the GICv3 interrupt controller.
> > It is based to some extent on previous patches from Shlomo and
> > Pavel, but the bulk of it has turned out to
On 2016/6/15 18:10, Peter Maydell wrote:
> On 15 June 2016 at 11:06, Peter Maydell wrote:
>> > On 15 June 2016 at 10:20, Andrew Jones wrote:
>>> >> There may be a bug in the freebsd kernel. Maybe they need the equivalent
>>> >> of Linux's
On 15 June 2016 at 15:02, Shannon Zhao wrote:
> I'll try tomorrow. By the way, if we disable secure extension, will the
> problem disappear?
No; it's because the secure extension is disabled that the problem
exists. If security is disabled then the guest gets to use both
On 2016年06月15日 18:10, Peter Maydell wrote:
> On 15 June 2016 at 11:06, Peter Maydell wrote:
>> > On 15 June 2016 at 10:20, Andrew Jones wrote:
>>> >> There may be a bug in the freebsd kernel. Maybe they need the equivalent
>>> >> of Linux's
On 15 June 2016 at 11:06, Peter Maydell wrote:
> On 15 June 2016 at 10:20, Andrew Jones wrote:
>> There may be a bug in the freebsd kernel. Maybe they need the equivalent
>> of Linux's 7c9b973061 "irqchip/gic-v3: Configure all interrupts as
>>
On 15 June 2016 at 10:20, Andrew Jones wrote:
> There may be a bug in the freebsd kernel. Maybe they need the equivalent
> of Linux's 7c9b973061 "irqchip/gic-v3: Configure all interrupts as
> non-secure Group-1". You could add the hack back that was in the initial
> posting of
On Wed, Jun 15, 2016 at 04:53:35PM +0800, Shannon Zhao wrote:
>
>
> On 2016/6/14 22:38, Peter Maydell wrote:
> > This series implements emulation of the GICv3 interrupt controller.
> > It is based to some extent on previous patches from Shlomo and
> > Pavel, but the bulk of it has turned out to
On 2016/6/14 22:38, Peter Maydell wrote:
> This series implements emulation of the GICv3 interrupt controller.
> It is based to some extent on previous patches from Shlomo and
> Pavel, but the bulk of it has turned out to be new code. (The
> combination of changing the underlying data
On 2016/6/14 22:38, Peter Maydell wrote:
> This series implements emulation of the GICv3 interrupt controller.
> It is based to some extent on previous patches from Shlomo and
> Pavel, but the bulk of it has turned out to be new code. (The
> combination of changing the underlying data
This series implements emulation of the GICv3 interrupt controller.
It is based to some extent on previous patches from Shlomo and
Pavel, but the bulk of it has turned out to be new code. (The
combination of changing the underlying data structures, adding
support for TrustZone and implementing
35 matches
Mail list logo