qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Marc Marí" <markmb@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Drew Jones <drjones@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	qemu-devel@nongnu.org, Kevin O'Connor <kevin@koconnor.net>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/5] Implement fw_cfg DMA interface
Date: Thu, 6 Aug 2015 23:11:48 +0200	[thread overview]
Message-ID: <20150806231148.5115a10c@markmb_rh> (raw)
In-Reply-To: <55C3C848.5070208@redhat.com>

On Thu, 6 Aug 2015 22:49:12 +0200
Laszlo Ersek <lersek@redhat.com> wrote:

[...]

> > +static void fw_cfg_dma_mem_write(void *opaque, hwaddr addr,
> > +                                 uint64_t value, unsigned size)
> > +{
> > +    FWCfgState *s = opaque;
> > +
> > +    s->dma_addr = be64_to_cpu(value);
> > +    fw_cfg_dma_transfer(s);
> > +}
> 
> So, this is similar to the ioport size limitation I described at the
> top. Namely,  I think that an Aarch32 guest won't be able to transfer
> a 64-bit value with a single MMIO access. (I believe double-width
> store instructions do exist, but they cannot be virtualized well.
> They trap, but the instruction syndrome register won't give enough
> info to the hypervisor.)
> 
> Therefore, the address of the dma control structure should be passed
> in two 32-bit wide accesses, both for the ioport mapping and the mmio
> mapping. This can be done in two ways:
> - write the two halves to the same register, and use a latch to
>   identify each 2nd access
> - use different addresses.
> 
> The latch sucks, because the guest has no way to bring the register
> to a known good state. Therefore:
> 
> In the ioport mapped case, the port range should go up to 0x519, and
> two outl's are going to be necessary in the guest. The documentation
> should spell out which outl (@ 0x512 or @ 0x516) will trigger the
> actual transfer.
> 
> (I vaguely recall that someone already described this, but I can't
> find the message!)

Previous answer to this patch, by Kevin O'Connor:

"So, I think this code needs to be able to handle a 32bit write to a
high bits address and then store those bits until the 32bit write to
the low bits address occurs.  (I'd also recommend that after every dma
transfer the stored high bits are reset to zero so that the common case
of a 32bit address can be performed with a single 32bit write to the
low bits field.)"

It's easier to do it this way.

Thanks for you comments
Marc

  reply	other threads:[~2015-08-07  1:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 11:00 [Qemu-devel] QEMU fw_cfg DMA interface Marc Marí
2015-08-06 11:01 ` [Qemu-devel] [PATCH 0/5] " Marc Marí
2015-08-06 11:01   ` [Qemu-devel] [PATCH 1/5] fw_cfg: document fw_cfg_modify_iXX() update functions Marc Marí
2015-08-06 11:01   ` [Qemu-devel] [PATCH 2/5] fw_cfg DMA interface documentation Marc Marí
2015-08-06 14:20     ` Kevin O'Connor
2015-08-07  8:12       ` Marc Marí
2015-08-06 11:01   ` [Qemu-devel] [PATCH 3/5] Implement fw_cfg DMA interface Marc Marí
2015-08-06 14:47     ` Kevin O'Connor
2015-08-06 14:59       ` Marc Marí
2015-08-07 20:40         ` Kevin O'Connor
2015-08-07 22:58           ` Laszlo Ersek
2015-08-06 20:49     ` Laszlo Ersek
2015-08-06 21:11       ` Marc Marí [this message]
2015-08-06 21:32         ` Laszlo Ersek
2015-08-07  7:26           ` Marc Marí
2015-08-07 12:14           ` Eric Blake
2015-08-06 11:01   ` [Qemu-devel] [PATCH 4/5] Enable fw_cfg DMA interface for ARM Marc Marí
2015-08-06 11:01   ` [Qemu-devel] [PATCH 5/5] Enable fw_cfg DMA interface for x86 Marc Marí
2015-08-06 12:27 ` [Qemu-devel] QEMU fw_cfg DMA interface Stefan Hajnoczi
2015-08-06 12:37   ` Marc Marí
2015-08-06 12:40     ` Stefan Hajnoczi
2015-08-06 15:30     ` Kevin O'Connor
2015-08-06 15:53       ` Marc Marí
2015-08-07  4:30         ` Kevin O'Connor
2015-08-17 22:08           ` Gerd Hoffmann

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=20150806231148.5115a10c@markmb_rh \
    --to=markmb@redhat.com \
    --cc=drjones@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).