qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-arm] [PATCH for-2.12] hw/intc/arm_gicv3: Fix secu


From: Andrew Jones
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH for-2.12] hw/intc/arm_gicv3: Fix secure-GIC NS ICC_PMR and ICC_RPR accesses
Date: Fri, 23 Mar 2018 11:08:43 +0100
User-agent: Mutt/1.6.0.1 (2016-04-01)

On Thu, Mar 22, 2018 at 05:42:02PM -0300, Philippe Mathieu-Daudé wrote:
> Hi Peter,
> 
> On 03/22/2018 03:29 PM, Peter Maydell wrote:
> > On 22 March 2018 at 14:23, Andrew Jones <address@hidden> wrote:
> >> On Thu, Mar 15, 2018 at 01:34:41PM +0000, Peter Maydell wrote:
> >>> If the GIC has the security extension support enabled, then a
> >>> non-secure access to ICC_PMR must take account of the non-secure
> >>> view of interrupt priorities, where real priorities 0..0x7f
> >>> are secure-only and not visible to the non-secure guest, and
> >>> priorities 0x80..0xff are shown to the guest as if they were
> >>> 0x00..0xff. We had the logic here wrong:
> >>
> >> 0x00..0x7f
> > 
> > I think 0x00..0xff is correct.
> 
> I guess Andrew only suggested to correct the hex prefix in your comment:
> - ... where real priorities 0..0x7f
> + ... where real priorities 0x00..0x7f

Actually I just hadn't thought that through properly. But thanks for
giving me the benefit of the doubt :-)

> > 
> > the NS view covers the whole 0x00..0xff range, but more sparsely.
> > (OK, technically you can't ever read 0xff, only 0xfe.)
> 

You can read 0xff, because 0xff will be written when either 0xfe or 0xff
are written. Then, when reading, priority == 0xff will fail the != 0xff
test (which is QEMU's implementation of the pseudo code where PRIMask()
is hardcoded to 0xff). In that case it'll just return the priority value
unchanged, which is 0xff.

Thanks,
drew



reply via email to

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