qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/7] Export the unassigned_mem read/write functi


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [PATCH 1/7] Export the unassigned_mem read/write functions.
Date: Fri, 5 Aug 2011 01:58:31 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Jul 24, 2011 at 01:56:00PM -0500, Anthony Liguori wrote:
> On 07/24/2011 11:42 AM, Richard Henderson wrote:
> >On 07/24/2011 06:28 AM, Anthony Liguori wrote:
> >>On 07/23/2011 02:17 PM, Richard Henderson wrote:
> >>>Signed-off-by: Richard Henderson<address@hidden>
> >>
> >>Why?
> >
> >So that I can write i/o functions like this:
> >
> >   switch (addr) {
> >   case 0: ...
> >   case 64: ...
> >   case 128: ...
> >   ...
> >   default:
> >     unassigned_mem_readl(...)
> >   }
> >
> >Perhaps Avi's rewrite makes this unnecessary; I browsed through
> >his patch set but didn't immediately see if there's a way for
> >the i/o function to return "failure".
> 
> What is returned by totally unregistered MMIO is defined by the
> chipset.  What's returned by an empty space in the MMIO space of a
> device is device specific.

Not really, IMO.

Im not going to say that HW does it this way or another because
different HW may do it different ways, but from my experience this
how most HW generally works:

Accesses to unmapped addresses are decoded, routed and finally handled
by the first node that realizes that the addr is unmapped. The action
might be to ignore or to signal some kind of error. AFAIK, most systems
will signal the error by sending an error back to the CPU via dedicated
control signals or by raising interrupts (the latter is very uncommon).

The common case is to signal an error via ctrl signals on the bus that
go back to the CPU and the final decision on what to do is made by the
CPU. QEMU currently doesnt model ctrl lines for bus accesses so entering
a per CPU xxx_unassigned_acceess function is pretty much in line with
most HW.

QEMU only models the data lanes so I think Richards patch is quite OK
because it brings the decission back to the CPU model.

I would prefer though, if the new Memory API would let devices pass
ctrl data back to the CPU in addition to the data lanes. That would
probably involve quite a bit of work though. CC:ing Avi, you might
have more input on this.

Cheers



reply via email to

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