On Thu, May 17, 2012 at 05:09:22PM -0500, Anthony Liguori wrote:
> On 05/16/2012 09:44 PM, Benjamin Herrenschmidt wrote:
> >On Wed, 2012-05-16 at 21:28 -0500, Anthony Liguori wrote:
> >
> >>>@@ -2794,6 +2795,9 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
> >>> {
> >>> RAMBlock *block;
> >>>
>
On Thu, 2012-05-17 at 17:09 -0500, Anthony Liguori wrote:
> ld/st should not ever be used by device emulation because they use a concept
> of
> "target endianness" that doesn't exist for devices.
Hrm, there's a bit of both, some of them even have explicit endianness
arguments and some of them a
On 05/16/2012 09:44 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-05-16 at 21:28 -0500, Anthony Liguori wrote:
@@ -2794,6 +2795,9 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
{
RAMBlock *block;
+/* We ensure ordering for all DMA transactions */
+dma_mb();
+
I get being conse
On Wed, May 16, 2012 at 09:28:39PM -0500, Anthony Liguori wrote:
> On 05/16/2012 07:52 PM, Benjamin Herrenschmidt wrote:
[snip]
> >@@ -2794,6 +2795,9 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
> > {
> > RAMBlock *block;
> >
> >+/* We ensure ordering for all DMA transactions */
> >+dma
On Wed, 2012-05-16 at 21:28 -0500, Anthony Liguori wrote:
> > @@ -2794,6 +2795,9 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
> > {
> > RAMBlock *block;
> >
> > +/* We ensure ordering for all DMA transactions */
> > +dma_mb();
> > +
>
> I get being conservative, but I don't think th
On 05/16/2012 07:52 PM, Benjamin Herrenschmidt wrote:
The emulated devices can run simultaneously with the guest, so
we need to be careful with ordering of load and stores done by
them to the guest system memory, which need to be observed in
the right order by the guest operating system.
In orde
The emulated devices can run simultaneously with the guest, so
we need to be careful with ordering of load and stores done by
them to the guest system memory, which need to be observed in
the right order by the guest operating system.
In order to avoid unnecessary overhead on i386, we define a new
