qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 16/17] spapr_vio: take care of creating our own


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH 16/17] spapr_vio: take care of creating our own AddressSpace/DMAContext
Date: Thu, 2 May 2013 12:24:55 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, May 01, 2013 at 06:09:21PM +0200, Paolo Bonzini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Il 01/05/2013 07:16, David Gibson ha scritto:
> > Lack of atomicity makes me a little nervous there, although I
> > guess its ok since qemu is single-threaded.
> 
> Yes.  The original plan was to add a boolean return value to
> address_space_rw, but I left this for later since I wasn't sure of the
> semantics for multipage writes.  What happens if the second half of
> the destination buffer has an invalid translation?  Right now it's
> atomic, but it sounds weird for real hardware.

So, in this regard I don't think real hardware would be atomic.  It
would write a certain amount, then generate some sort of bus error
when it hits the bad translation.  So in general I expect the (guest)
OS would need to treat the target of in-flight device to host DMAs as
having undefined contents if there's a bus error like that.  It would
depend on bus and possibly individual device conventions what it could
assume about which DMAs are interrupted, and which might still be
in-flight.

That is, in this sense, we don't expect the hardware to behave
atomically at all.  The atomicity I was concerned about was atomicity
of checking permissions and returning an error based on that check.

So, case, I think an error return value from address_space_rw() is
appropriate.  Semantics would be that if an error is returned you
can't tell if the operation has not started, completed, or somewhere
in the middle.

-- 
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: signature.asc
Description: Digital signature


reply via email to

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