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 no-security-extensions system, leaving the interrupts
> in Group 0 is still
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", because
the OS will receive
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 June 2016 at 06:10, Peter Maydell wrote:
>>
>> A qui
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:
>
> A quick scan through http://fxr.watson.org/fxr/source/arm64/
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 http://fxr.watson.org/fxr/source/arm64/arm64/gic_v3.c
doesn't seem to show i
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 http://fxr.watson.org/fxr/source/arm64/arm64/gic_v3.c
> >>> do
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 setting the IGROUPR registers anywhere,
>>> so it pr
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 find that if UEFI is config
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 fix?
>>
>> Probably you'll find that if UEFI is
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 interrupt
> groups FreeBSD will
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 probably is a guest bug. (You can use "-d 'trace:
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 the tracepoints for the GIC
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 2016
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 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 wrote:
> > >> > On 06/21/16 19:21, Peter Maydell wrote:
>>> > >>> >> and add a n
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 that
> >>> >> the pro
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 and
>>> >> GICR_IGROU
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 it's using as
>> gro
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 really on CC.
>
> H
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 a freebsd guest. When
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 +0200,
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 message:
The GICv3 emu
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 emulation is not yet in mas
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 line, the guest can'
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 if I use gic-version=
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 b
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 7c9b973061 "irqchip/gic-v3: Configure all interrupts as
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
group 0 and group 1 IRQs
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 7c9b973061 "irqchip/gic-v3: Configure all interrupts as
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
>> non-secure Group-1". You could add the hack back that
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 this series to see i
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 b
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 structures,
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 structures,
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 prop
35 matches
Mail list logo