On Mon, 12 Dec 2011 14:45:26 +, Paul Brook p...@codesourcery.com wrote:
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?
On Mon, 2011-12-12 at 02:52 +, Paul Brook wrote:
I've taken a look at the virtion-mmio spec, and it looks fairly
reasonable.
The only thing I'd change is the GuestPageSize/QueuePFN mess. Seems like
just
using straight 64-bit addresses would be a better solution. Maybe split into
a
I noticed the virtio-mmio spec has an interrupt status register. On
x86 and virtio-pci things are moving towards Message Signalled
Interrupts and virtqueues having their own interrupts for better
performance and flexibility. Any thoughts on how 1 interrupt per
virtqueue works for virtio-mmio?
On Mon, 2011-12-12 at 12:14 +, Stefan Hajnoczi wrote:
I noticed the virtio-mmio spec has an interrupt status register. On
x86 and virtio-pci things are moving towards Message Signalled
Interrupts and virtqueues having their own interrupts for better
performance and flexibility. Any
On Mon, Dec 12, 2011 at 12:28:27PM +, Pawel Moll wrote:
On Mon, 2011-12-12 at 12:14 +, Stefan Hajnoczi wrote:
I noticed the virtio-mmio spec has an interrupt status register. On
x86 and virtio-pci things are moving towards Message Signalled
Interrupts and virtqueues having their
On Mon, 2011-12-12 at 13:12 +, Michael S. Tsirkin wrote:
On Mon, Dec 12, 2011 at 12:28:27PM +, Pawel Moll wrote:
On Mon, 2011-12-12 at 12:14 +, Stefan Hajnoczi wrote:
I noticed the virtio-mmio spec has an interrupt status register. On
x86 and virtio-pci things are moving
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
On Mon, 2011-12-12 at 14:45 +, Paul Brook wrote:
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.
This sounds good to me. If we define the reset
On Mon, Dec 12, 2011 at 12:28 PM, Pawel Moll pawel.m...@arm.com wrote:
On Mon, 2011-12-12 at 12:14 +, Stefan Hajnoczi wrote:
I noticed the virtio-mmio spec has an interrupt status register. On
x86 and virtio-pci things are moving towards Message Signalled
Interrupts and virtqueues having
On 12 December 2011 15:11, Stefan Hajnoczi stefa...@gmail.com wrote:
If there aren't already then pretty soon ARM-based systems will deal
with PCIe and Message Signalled Interrupts. Are you sure new ARM
boards are constraints to a small number of physical interrupts?
Depends what you mean by
On Mon, 2011-12-12 at 15:11 +, Stefan Hajnoczi wrote:
If there aren't already then pretty soon ARM-based systems will deal
with PCIe and Message Signalled Interrupts.
Actually PCI is not an alien in ARM world - we had platforms with PCI
long time ago. And new SOCs aimed at servers come
I'm not sure what guest software uses the syborg virtio transport.
It is/was a virtual reference platform for SymbianOS. However since then
the Symbian Foundation got shot in the back of the head and the rest of
Nokia jumped ship to Windows, so I'd be surprised if anyone really cares
[Replying to various bits of this thread all at once]
* you have to specify which kind of virtio device you want in the
board model. In particular this means that for virtio-blk the user
has to say -drive if=none,file=whatever.img,id=myimg
-global virtio-blk-mmio.drive=myimg or the
On 12/09/2011 09:16 AM, Paul Brook wrote:
[Replying to various bits of this thread all at once]
* you have to specify which kind of virtio device you want in the
board model. In particular this means that for virtio-blk the user
has to say -drive if=none,file=whatever.img,id=myimg
On Wed, 2011-11-16 at 19:56 +, Anthony Liguori wrote:
On 11/16/2011 12:41 PM, Peter Maydell wrote:
Pawel may have more detail, but to me the significant difference
is that virtio-mmio is an implementation of a specification extension
agreed with the virtio spec maintainers, whereas
On 11/17/2011 12:20 PM, Pawel Moll wrote:
Correct. Syborg virtio was something Paul Brook did bit is not an official
virtio transport as far as Linux or the spec is concerned.
Honestly, that's the first time I hear about it, and as I'm not allowed
to look at qemu code (legal reasons, just
On 11/14/2011 03:55 PM, Peter Maydell wrote:
This set of patches implements the QEMU end of the MMIO virtio transport
(as specified by Appendix X of the latest virtio spec from here
http://ozlabs.org/~rusty/virtio-spec/virtio.pdf
and implemented by patches which I think are going into Linux
On 16 November 2011 14:33, Paolo Bonzini pbonz...@redhat.com wrote:
On 11/14/2011 03:55 PM, Peter Maydell wrote:
This set of patches implements the QEMU end of the MMIO virtio transport
(as specified by Appendix X of the latest virtio spec from here
On 11/16/2011 12:41 PM, Peter Maydell wrote:
On 16 November 2011 14:33, Paolo Bonzinipbonz...@redhat.com wrote:
On 11/14/2011 03:55 PM, Peter Maydell wrote:
This set of patches implements the QEMU end of the MMIO virtio transport
(as specified by Appendix X of the latest virtio spec from
On Mon, Nov 14, 2011 at 2:55 PM, Peter Maydell peter.mayd...@linaro.org wrote:
This set of patches implements the QEMU end of the MMIO virtio transport
(as specified by Appendix X of the latest virtio spec from here
http://ozlabs.org/~rusty/virtio-spec/virtio.pdf
and implemented by patches
20 matches
Mail list logo
