qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regi


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions
Date: Thu, 25 Oct 2012 14:12:41 +0100

On 25 October 2012 14:03, Peter Crosthwaite
<address@hidden> wrote:
> On Thu, Oct 25, 2012 at 10:19 PM, Gerd Hoffmann <address@hidden> 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 registers (and sucessfully fakes reading and
>>> writing the registers with no side effects).
>>
>> Should not be needed, memory api should deal with that properly.
>
> CC Avi,
>
> Whats going on here is there is a container of size 0x1000 created
> with memory_region_init() and a handful of small subregions are
> populated. the container is then mapped to a 0x1000 size region of the
> system memory. What is supposed to happen when the guest access a
> region in the container for which no subregion has been added? For me
> it was a segfault, so i needed this patch for guest to proceed past
> accesses these undefined regions.

 (1) what does the hardware do? If the hardware device has (the
 equivalent of) an N bit address bus and treats accesses to unused
 addresses within the memory range defined by that bus width as RAZ/WI
 then that's what we should be modelling.
 If the hardware has real registers in this range we should also be
 modelling them (possibly as RAZ/WI with a LOG_UNIMP diagnostic).

 (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 in the guest
 CPU taking a data abort or prefetch abort. I don't think our
 memory system currently has any way of saying "for this access
 generate an exception"...

 (3) I don't think "qemu segfaults" is a good response to bad
 guest behaviour so that needs fixing somehow even if we can't
 model what the h/w does :-)

-- PMM



reply via email to

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