Re: [Qemu-devel] [PATCH 15/30] memory: add address_space_valid

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

On Sat, May 25, 2013 at 10:23:32AM +0100, Peter Maydell wrote:
> On 25 May 2013 04:44, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Fri, May 24, 2013 at 11:52:17AM +0100, Peter Maydell wrote:
> >> So when *is* it a good idea to use this API? In real
> >> hardware you don't usually get a "tell me whether this
> >> access would succeed if I did it" bus operation -- you
> >> just do the operation and the memory transaction either
> >> succeeds or it doesn't. Are we modelling something that
> >> really exists in hardware on spapr here?
> >
> > So, as a general rule, you should just attempt the access and handle
> > failures - this is a bad interface.  The reason I added it, however,
> > is that the PAPR specification mandates that the virtual LAN pre-check
> > various buffers when they're registered, and return specific errors if
> > they're not mapped to valid memory.  Since we have nothing to read or
> > write at that point, adding this interface was the only way I could
> > see to implement that requirement.
> 
> Would it work to just read and throw away the result of the read?

Not when checking for writability.

> > Or... a bit more charitably: You should always handle failures at the
> > point of read or write, but using this interface can give you an
> > earlier, and therefore potentially easier to analyze, error in the
> > more common failure cases, even if there are more complex cases where
> > the pre-check succeeds but the read/write still fails later.
> 
> There's also the converse case where the pre-check fails but
> doing the operation at the proper time would succeed, in
> which case where we're modelling real hardware we would
> be doing it wrong. So the set of cases where it's OK to
> pre-check seems a bit limited.

Whether originally real or otherwise, this is a question of faithfully
implementing what the hardware is supposed to do.  In the case of the
PAPR llan, the (virtual) hardware specification says that the buffer
accessibility is checked at buffer add time, and the driver won't work
if it only makes the buffers accessible between that point and the
actual buffer access.  It would be entirely possible to design real
hardware with similar behaviour (probe buffer accessibility when a
descriptor is added to a pool, say), although it's not the sort of
thing hardware people generally do.

So, certainly qemu should not go using this pre-check when the
hardware it's emulating does not do such a check.  Designing hardware
that does do a pre-check is not, IMO, a good idea on balance, but the
point is that there is a reason (albeit, not a great one) you might
want to design the (possibly virtual) hardware that way.

As an aside, when you consider devices with embedded firmware - which
is practically everything these days - the distinction between "real"
hardware and virtual hardware can get kind of blurry.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]