From: Paul Brook <paul@codesourcery.com>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Rusty Russell <rusty@rustcorp.com.au>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
virtualization@lists.linux-foundation.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport
Date: Mon, 12 Dec 2011 14:45:26 +0000 [thread overview]
Message-ID: <201112121445.27873.paul@codesourcery.com> (raw)
In-Reply-To: <1323688579.2391.11.camel@hornet.cambridge.arm.com>
> I can do that, but not this year (on holiday from Friday 16th, without
> any access to Internet whatsoever :-) One think to be decided is in what
> order the halfs should be filled? Low first, then high? High then low?
> Does it matter at all? :-)
My inital though was that you shouldn't be changing this value when the ring
is enabled. Unfortunately you disable the ring by setting the address to zero
so that argument doesn't work :-/
I suggest that the device to buffer writes to the high part, and construct the
actual 64-bit value when the low part is written. That allows 32-bit guests
can ignore the high part entirely. Requiring the guest always write high then
low also works, though I don't see any benefit to either guest or host.
Acting on writes as soon as they occur is not a viable option as it causes the
device to be enabled before the full address has bee written. You could say
the address takes effect after both halves have been written, writes must come
in pairs, but may occur in either order. However there is a risk that host
and guest will somehow get out of sync on which values pair together, so IMO
this is a bad idea.
If you can't stomach the above then I guess changing the condition for ring
enablement to QueueNum != 0 and rearanging the configuration sequence
appropriately would also do the trick. Having this be different between PCI
and mmio is probably not worth the confusion though.
Paul
next prev parent reply other threads:[~2011-12-12 14:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 14:55 [Qemu-devel] [RFC 0/4] virtio-mmio transport Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 1/4] virtio: Add support for guest setting of queue size Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 2/4] virtio: Support transports which can specify the vring alignment Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 3/4] Add MMIO based virtio transport Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 4/4] hw/vexpress.c: Add MMIO " Peter Maydell
2011-11-14 15:41 ` [Qemu-devel] [RFC 0/4] virtio-mmio transport Stefan Hajnoczi
2011-11-16 14:33 ` Paolo Bonzini
2011-11-16 18:41 ` Peter Maydell
2011-11-16 19:56 ` Anthony Liguori
2011-11-17 11:20 ` Pawel Moll
2011-11-17 11:44 ` Paolo Bonzini
2011-12-09 15:16 ` Paul Brook
2011-12-09 15:57 ` Anthony Liguori
2011-12-12 2:52 ` Paul Brook
2011-12-12 11:16 ` Pawel Moll
2011-12-12 14:45 ` Paul Brook [this message]
2011-12-12 14:51 ` Pawel Moll
2011-12-16 5:36 ` Rusty Russell
2011-12-12 12:14 ` Stefan Hajnoczi
2011-12-12 12:28 ` Pawel Moll
2011-12-12 13:12 ` Michael S. Tsirkin
2011-12-12 13:19 ` Pawel Moll
2011-12-12 15:11 ` Stefan Hajnoczi
2011-12-12 15:18 ` Peter Maydell
2011-12-12 15:21 ` Pawel Moll
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=201112121445.27873.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=pawel.moll@arm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
/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).