On 25 October 2012 14:59, Peter Crosthwaite
wrote:
> On Thu, Oct 25, 2012 at 11:50 PM, Peter Maydell
> wrote:
>> On 25 October 2012 14:41, Avi Kivity wrote:
>>> wrt decode duplication, I've been thinking of a single ->service()
>>> callback that accepts a Transaction argument, including all the
On Thu, Oct 25, 2012 at 11:50 PM, Peter Maydell
wrote:
> On 25 October 2012 14:41, Avi Kivity wrote:
>> On 10/25/2012 03:28 PM, Peter Maydell wrote:
>>> On 25 October 2012 14:21, Avi Kivity wrote:
You could easily have the top-level container have ->ops that generate
an exception.
>>>
On 10/25/2012 03:50 PM, Peter Maydell wrote:
> On 25 October 2012 14:41, Avi Kivity wrote:
>> On 10/25/2012 03:28 PM, Peter Maydell wrote:
>>> On 25 October 2012 14:21, Avi Kivity wrote:
You could easily have the top-level container have ->ops that generate
an exception.
>>>
>>> Ah, yes
On 25 October 2012 14:41, Avi Kivity wrote:
> On 10/25/2012 03:28 PM, Peter Maydell wrote:
>> On 25 October 2012 14:21, Avi Kivity wrote:
>>> You could easily have the top-level container have ->ops that generate
>>> an exception.
>>
>> Ah, yes, there's an 'accepts' callback. (That's kind of awkw
On 10/25/2012 03:28 PM, Peter Maydell wrote:
> On 25 October 2012 14:21, Avi Kivity wrote:
>> On 10/25/2012 03:12 PM, Peter Maydell wrote:
>>> (2) what should the memory system do for accesses where there is
>>> no memory region? This is really system specific as it depends
>>> what the bus fab
On 25 October 2012 14:21, Avi Kivity wrote:
> On 10/25/2012 03:12 PM, Peter Maydell wrote:
>> (2) what should the memory system do for accesses where there is
>> no memory region? This is really system specific as it depends
>> what the bus fabric does. For ARM the usual thing would be to
>> g
On 10/25/2012 03:12 PM, Peter Maydell wrote:
> (2) what should the memory system do for accesses where there is
> no memory region? This is really system specific as it depends
> what the bus fabric does. For ARM the usual thing would be to
> generate a decode error response which will result i
On 10/25/2012 03:03 PM, Peter Crosthwaite wrote:
> On Thu, Oct 25, 2012 at 10:19 PM, Gerd Hoffmann wrote:
>> On 10/25/12 11:47, Peter Crosthwaite wrote:
>>> Just put RAM regions in the unimplemented spaces in the MMIO region. These
>>> regions have undefined behaviour, but this at least stops QEMU
On 25 October 2012 14:03, Peter Crosthwaite
wrote:
> On Thu, Oct 25, 2012 at 10:19 PM, Gerd Hoffmann wrote:
>> On 10/25/12 11:47, Peter Crosthwaite wrote:
>>> Just put RAM regions in the unimplemented spaces in the MMIO region. These
>>> regions have undefined behaviour, but this at least stops Q
On Thu, Oct 25, 2012 at 10:19 PM, Gerd Hoffmann wrote:
> On 10/25/12 11:47, Peter Crosthwaite wrote:
>> Just put RAM regions in the unimplemented spaces in the MMIO region. These
>> regions have undefined behaviour, but this at least stops QEMU from
>> segfaulting
>> when the guest bangs on these
On 10/25/12 11:47, Peter Crosthwaite wrote:
> Just put RAM regions in the unimplemented spaces in the MMIO region. These
> regions have undefined behaviour, but this at least stops QEMU from
> segfaulting
> when the guest bangs on these registers (and sucessfully fakes reading and
> writing the re
Just put RAM regions in the unimplemented spaces in the MMIO region. These
regions have undefined behaviour, but this at least stops QEMU from segfaulting
when the guest bangs on these registers (and sucessfully fakes reading and
writing the registers with no side effects).
Signed-off-by: Peter Cr
12 matches
Mail list logo
