All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: vineshp@xilinx.com,
	Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
	qemu-devel@nongnu.org, john.williams@xilinx.com,
	Gerd Hoffmann <kraxel@redhat.com>,
	edgar.iglesias@gmail.com
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	[thread overview]
Message-ID: <5089418C.2000003@redhat.com> (raw)
In-Reply-To: <CAFEAcA9qf6dLUTGm5+bKOH74aLSeKi=_m8G7i3-fVLGM7AooiQ@mail.gmail.com>

On 10/25/2012 03:28 PM, Peter Maydell wrote:
> On 25 October 2012 14:21, Avi Kivity <avi@redhat.com> 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	other threads:[~2012-10-25 13:41 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-25  9:47 [Qemu-devel] [PATCH v1 0/8] Sysbus EHCI + Zynq USB Peter Crosthwaite
2012-10-25  9:47 ` [Qemu-devel] [PATCH v1 1/8] usb/ehci: parameterise the register region offsets Peter Crosthwaite
2012-10-25 12:04   ` Gerd Hoffmann
2012-10-25  9:47 ` [Qemu-devel] [PATCH v1 2/8] usb/ehci: Abstract away PCI DMA API Peter Crosthwaite
2012-10-25  9:47 ` [Qemu-devel] [PATCH v1 3/8] usb/ehci: seperate out PCIisms Peter Crosthwaite
2012-10-25 12:08   ` Gerd Hoffmann
2012-10-25 12:44     ` Peter Crosthwaite
2012-10-25 12:57       ` Gerd Hoffmann
2012-10-25 13:19         ` Peter Crosthwaite
2012-10-25  9:47 ` [Qemu-devel] [PATCH v1 4/8] usb/ehci: Add usb-ehci-sysbus Peter Crosthwaite
2012-10-25  9:55   ` Peter Maydell
2012-10-25 13:17     ` Avi Kivity
2012-10-25 12:10   ` Gerd Hoffmann
2012-10-25 12:39     ` Peter Crosthwaite
2012-10-25  9:47 ` [Qemu-devel] [PATCH v1 5/8] xilinx_zynq: add USB controllers Peter Crosthwaite
2012-10-25 12:12   ` Gerd Hoffmann
2012-10-25 12:16     ` Peter Maydell
2012-10-25 12:56       ` Peter Crosthwaite
2012-10-25 13:14         ` Gerd Hoffmann
2012-10-25 13:24           ` Peter Crosthwaite
2012-10-25 13:49             ` Gerd Hoffmann
2012-10-25 14:10               ` Gerd Hoffmann
2012-10-25 23:54                 ` Peter Crosthwaite
2012-10-25 23:59                   ` Peter Crosthwaite
2012-10-26  6:49                     ` Gerd Hoffmann
2012-10-26  6:59                       ` Peter Crosthwaite
2012-10-25  9:47 ` [Qemu-devel] [PATCH v1 6/8] usb/ehci: Guard definition of EHCI_DEBUG Peter Crosthwaite
2012-10-25  9:47 ` [Qemu-devel] [PATCH v1 7/8] usb/ehci: Debug mode compile fixes Peter Crosthwaite
2012-10-25  9:47 ` [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions Peter Crosthwaite
2012-10-25 12:19   ` Gerd Hoffmann
2012-10-25 13:03     ` Peter Crosthwaite
2012-10-25 13:12       ` Peter Maydell
2012-10-25 13:21         ` Avi Kivity
2012-10-25 13:28           ` Peter Maydell
2012-10-25 13:41             ` Avi Kivity [this message]
2012-10-25 13:50               ` Peter Maydell
2012-10-25 13:57                 ` Avi Kivity
2012-10-25 13:59                 ` Peter Crosthwaite
2012-10-25 14:08                   ` Peter Maydell
2012-10-25 13:20       ` Avi Kivity
2012-10-29 14:08 ` [Qemu-devel] [PATCH v1 0/8] Sysbus EHCI + Zynq USB Peter Crosthwaite
2012-10-30  7:20   ` Gerd Hoffmann
2012-10-30  8:24     ` Peter Crosthwaite
2012-10-30 10:30       ` Gerd Hoffmann
2012-10-30 12:14       ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5089418C.2000003@redhat.com \
    --to=avi@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=john.williams@xilinx.com \
    --cc=kraxel@redhat.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vineshp@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.