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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions
Date: Thu, 25 Oct 2012 15:41:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

On 10/25/2012 03:28 PM, Peter Maydell wrote:
> On 25 October 2012 14:21, Avi Kivity <address@hidden> 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
>>>  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"...
>>>
>>
>> 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 awkward
> as an API because it means your decode logic gets spread between
> read, write and accept: there are some devices where it would be
> nice to have the 'default:' case of the address switch say "unknown
> offset, raise decode error". If the read callback took a uint64_t*
> rather than returning the read data, we could make both read and
> write return a success/decode-error type of status result.)

I actually forgot about ->accepts().  But it isn't needed for this use
case, just have the lowest priority region (the container) implement
->read/write that generate the exception.  If some other region decodes,
the container region will be ignored, if nothing decodes, you get your
exception.

wrt decode duplication, I've been thinking of a single ->service()
callback that accepts a Transaction argument, including all the details
(offset, data, and direction).  We may also do something like
MemoryRegionPortio, but not hacky, that lets you have a MemoryRegion for
each register.  That means that instead of writing two large functions
that duplicates the decode, you write one function per register, and
switch on transfer direction.

-- 
error compiling committee.c: too many arguments to function



reply via email to

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