On Fri, 11 Nov 2022 at 13:23, Philippe Mathieu-Daudé wrote:
>
> On 31/10/22 14:03, Peter Maydell wrote:
> > On Mon, 31 Oct 2022 at 12:08, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> On 4/10/22 16:54, Peter Maydell wrote:
> >>> On Tue, 4 Oct 2022 at 14:33, Alex Bennée wrote:
>
>
>
Philippe Mathieu-Daudé writes:
> On 31/10/22 14:03, Peter Maydell wrote:
>> On Mon, 31 Oct 2022 at 12:08, Philippe Mathieu-Daudé
>> wrote:
>>>
>>> On 4/10/22 16:54, Peter Maydell wrote:
On Tue, 4 Oct 2022 at 14:33, Alex Bennée wrote:
>
>
> Peter Maydell writes:
>> The
On 31/10/22 14:03, Peter Maydell wrote:
On Mon, 31 Oct 2022 at 12:08, Philippe Mathieu-Daudé wrote:
On 4/10/22 16:54, Peter Maydell wrote:
On Tue, 4 Oct 2022 at 14:33, Alex Bennée wrote:
Peter Maydell writes:
The MSC is in the address map like most other stuff, and thus there is
no
On Mon, 31 Oct 2022 at 12:08, Philippe Mathieu-Daudé wrote:
>
> On 4/10/22 16:54, Peter Maydell wrote:
> > On Tue, 4 Oct 2022 at 14:33, Alex Bennée wrote:
> >>
> >>
> >> Peter Maydell writes:
> >>> The MSC is in the address map like most other stuff, and thus there is
> >>> no restriction on
On 4/10/22 16:54, Peter Maydell wrote:
On Tue, 4 Oct 2022 at 14:33, Alex Bennée wrote:
Peter Maydell writes:
The MSC is in the address map like most other stuff, and thus there is
no restriction on whether it can be accessed by other things than CPUs
(DMAing to it would be silly but is
On Tue, 4 Oct 2022 at 14:33, Alex Bennée wrote:
>
>
> Peter Maydell writes:
> > The MSC is in the address map like most other stuff, and thus there is
> > no restriction on whether it can be accessed by other things than CPUs
> > (DMAing to it would be silly but is perfectly possible).
> >
> >
Peter Maydell writes:
> On Wed, 28 Sept 2022 at 17:42, Richard Henderson
> wrote:
>>
>> On 9/27/22 07:14, Alex Bennée wrote:
>> > --- a/hw/misc/tz-msc.c
>> > +++ b/hw/misc/tz-msc.c
>> > @@ -137,11 +137,11 @@ static MemTxResult tz_msc_read(void *opaque, hwaddr
>> > addr, uint64_t *pdata,
>> >
On Wed, 28 Sept 2022 at 17:42, Richard Henderson
wrote:
>
> On 9/27/22 07:14, Alex Bennée wrote:
> > --- a/hw/misc/tz-msc.c
> > +++ b/hw/misc/tz-msc.c
> > @@ -137,11 +137,11 @@ static MemTxResult tz_msc_read(void *opaque, hwaddr
> > addr, uint64_t *pdata,
> > return MEMTX_OK;
> >
On 9/27/22 07:14, Alex Bennée wrote:
+/*
+ * Every memory transaction comes from a specific place which defines
+ * how requester_id should be handled. For CPU's the requester_id is
+ * the global cpu_index which needs further processing if you need to
+ * work out which socket or complex it
We currently have hacks across the hw/ to reference current_cpu to
work out what the current accessing CPU is. This breaks in some cases
including using gdbstub to access HW state. As we have MemTxAttrs to
describe details about the access lets extend it so CPU accesses can
be explicitly marked.
10 matches
Mail list logo