On Mon, 12 Dec 2011 14:45:26 +, Paul Brook 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?
> > Does it matte
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 wi
On 12 December 2011 15:11, Stefan Hajnoczi 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 "small number".
On Mon, Dec 12, 2011 at 12:28 PM, 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 own in
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 re
> 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 chang
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 mov
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 th
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 th
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?
My
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 int
> >> 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 real
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
[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
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, ju
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, wherea
On 11/16/2011 12:41 PM, Peter Maydell wrote:
On 16 November 2011 14:33, Paolo Bonzini 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
http://ozlabs.org/
On 16 November 2011 14:33, Paolo Bonzini 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
>> http://ozlabs.org/~rusty/virtio-spec/virtio.pdf
>> and
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 3.2).
On Mon, Nov 14, 2011 at 2: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
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 3.2).
I submit this only as an RFC because although
21 matches
Mail list logo
