All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alexander Graf <agraf@suse.de>, Muli Ben-Yehuda <muli@il.ibm.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH] Enable non page boundary BAR device assignment
Date: Thu, 10 Dec 2009 14:12:43 +0200	[thread overview]
Message-ID: <20091210121243.GU7645@redhat.com> (raw)
In-Reply-To: <20091210112139.GA11956@redhat.com>

On Thu, Dec 10, 2009 at 01:21:40PM +0200, Michael S. Tsirkin wrote:
> On Thu, Dec 10, 2009 at 12:09:13PM +0100, Alexander Graf wrote:
> > 
> > On 10.12.2009, at 11:56, Michael S. Tsirkin wrote:
> > 
> > > On Thu, Dec 10, 2009 at 12:37:37PM +0200, Muli Ben-Yehuda wrote:
> > >> On Thu, Dec 10, 2009 at 11:31:01AM +0100, Alexander Graf wrote:
> > >> 
> > >>>> What do you have in mind for such a rewrite?
> > >>> 
> > >>> I'd like to see it more well-abstracted and versatile. I don't see
> > >>> an obvious reason why we shouldn't be able to use a physical device
> > >>> in a TCG target :-).
> > >> 
> > >> mmio and pio are easy, DMA you'd need an IOMMU for security, or
> > >> whatever uio does just for translation,
> > > 
> > > uio currently does not support DMA, but I plan to fix this
> > > 
> > >> and interrupts you probably
> > >> get for free from uio. Seems eminently doable to me. Why you'd want to
> > >> is another matter :-)
> > >> 
> > >> Cheers,
> > >> Muli
> > > 
> > > The list above ignores the biggest issue: you would have to change TCG
> > > code generation to make this work.
> > > 
> > > For example, I think a read memory barrier is currently ignored in
> > > translation, and host CPU will reorder reads.  Some drivers might also
> > > rely on ordering guarantees that depend on CPU cacheline sizes.  Atomics
> > > is another bag of tricks but I expect atomics on a DMA memory are not
> > > widely used.
> > 
> > Since we'd use the mmio callbacks for MMIO we'd be strictly ordered, no?
> > 
> > Alex
> 
> Not unless you issue appropriate host memory barriers on mmio callbacks (kvm currently
> uses a lock for this, which has an implicit barrier, but I do not
> think TCG does this).
> 
> But even then, it depends on the device, for some devices DMA memory
> reads/writes might depend on each other. Look at virtio as an example, a
> real device might have the same semantics.  As a simpler example, some
> devices DMA the following into ring in host memory to signal data
> available:
> - valid tag
> - data length
> host will read tag, and when it's valid use data length,
May be:
- data length
- valid tag
Otherwise how can you guaranty that at the time tag is valid data
length is already up-to-date and not in process to be written? An on
arch such as Altix DMA from device to memory can arrive out of order
if memory is not mapped in a special way, but then DMA is slow.

--
			Gleb.

  reply	other threads:[~2009-12-10 12:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09 17:38 [PATCH] Enable non page boundary BAR device assignment Alexander Graf
2009-12-09 20:49 ` Michael S. Tsirkin
2009-12-09 21:06   ` Alexander Graf
2009-12-10 10:35     ` Avi Kivity
2009-12-10  5:16 ` Muli Ben-Yehuda
2009-12-10  9:35   ` Alexander Graf
2009-12-10 10:21     ` Muli Ben-Yehuda
2009-12-10  9:43   ` Michael S. Tsirkin
2009-12-10  9:52     ` Alexander Graf
2009-12-10 10:08       ` Alexander Graf
2009-12-10 10:27         ` Michael S. Tsirkin
2009-12-10 10:31           ` Alexander Graf
2009-12-10 10:42             ` Michael S. Tsirkin
2009-12-10 10:23       ` Muli Ben-Yehuda
2009-12-10 10:31         ` Alexander Graf
2009-12-10 10:37           ` Muli Ben-Yehuda
2009-12-10 10:56             ` Michael S. Tsirkin
2009-12-10 11:09               ` Alexander Graf
2009-12-10 11:21                 ` Michael S. Tsirkin
2009-12-10 12:12                   ` Gleb Natapov [this message]
2009-12-10 11:28               ` Muli Ben-Yehuda
2009-12-10 11:34                 ` Alexander Graf
2009-12-10 11:46                   ` Michael S. Tsirkin
2009-12-10 11:37                 ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2009-12-10 23:06 Alexander Graf
2009-12-11 11:05 ` Michael S. Tsirkin
2009-12-15 18:16   ` Alexander Graf
2009-12-15 18:20     ` Michael S. Tsirkin
2009-12-15 18:24       ` Alexander Graf
2009-12-16 20:12         ` Muli Ben-Yehuda

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=20091210121243.GU7645@redhat.com \
    --to=gleb@redhat.com \
    --cc=agraf@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=muli@il.ibm.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.