[Top][All Lists]
[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
- Re: [Qemu-devel] [PATCH v1 4/8] usb/ehci: Add usb-ehci-sysbus, (continued)
- [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Peter Crosthwaite, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Gerd Hoffmann, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Peter Crosthwaite, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Peter Maydell, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Avi Kivity, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Peter Maydell, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions,
Avi Kivity <=
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Peter Maydell, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Avi Kivity, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Peter Crosthwaite, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Peter Maydell, 2012/10/25
- Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions, Avi Kivity, 2012/10/25
[Qemu-devel] [PATCH v1 7/8] usb/ehci: Debug mode compile fixes, Peter Crosthwaite, 2012/10/25
[Qemu-devel] [PATCH v1 6/8] usb/ehci: Guard definition of EHCI_DEBUG, Peter Crosthwaite, 2012/10/25
[Qemu-devel] [PATCH v1 5/8] xilinx_zynq: add USB controllers, Peter Crosthwaite, 2012/10/25