Rusty Russell wrote:
On Saturday 10 November 2007 10:45:38 Anthony Liguori wrote:
The problem is the ABI. We can either require that PCI configuration
values are accessed with natural instructions, or it makes very little
sense to use the PCI configuration space for virtio configuration
info
On Saturday 10 November 2007 10:45:38 Anthony Liguori wrote:
> The problem is the ABI. We can either require that PCI configuration
> values are accessed with natural instructions, or it makes very little
> sense to use the PCI configuration space for virtio configuration
> information.
To me it
Rusty Russell wrote:
On Friday 09 November 2007 09:33:04 Anthony Liguori wrote:
switch (addr) {
case VIRTIO_BLK_CONFIG_MAX_SEG:
return vdev->max_seg & 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 1:
return (vdev->max_seg >> 8) & 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 2:
return (vdev->max_s
On Friday 09 November 2007 09:33:04 Anthony Liguori wrote:
> I really want to make sure that if a guest tries
> to read a 4-byte PCI config field, that it does so using an "outl"
> instruction so that in my QEMU backend
So you want to enforce PCI requirements onto virtio config accesses. This
do
Dor Laor wrote:
ron minnich wrote:
Hi, I'm sorry, I've been stuck on other things (NFS RDMA anyone?) and
missed part of this discussion.
Is it really the case that operations on virtio devices will involve
outl/inl etc.?
What's the problem with them?
Except for the kick event it's not perfor
ron minnich wrote:
Hi, I'm sorry, I've been stuck on other things (NFS RDMA anyone?) and
missed part of this discussion.
Is it really the case that operations on virtio devices will involve
outl/inl etc.?
No, this is just for the PCI virtio transport. lguest's virtio
transport uses hyperc
Hi, I'm sorry, I've been stuck on other things (NFS RDMA anyone?) and
missed part of this discussion.
Is it really the case that operations on virtio devices will involve
outl/inl etc.?
Apologies in advance for my failure to pay attention.
thanks
ron
-
To unsubscribe from this list: send the li
Rusty Russell wrote:
On Thursday 08 November 2007 13:41:16 Anthony Liguori wrote:
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config->get() ops
On Thursday 08 November 2007 13:41:16 Anthony Liguori wrote:
> Rusty Russell wrote:
> > On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
> >> I would prefer that the virtio API not expose a little endian standard.
> >> I'm currently converting config->get() ops to ioreadXX depending on
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config->get() ops to ioreadXX depending on the
size which already does the endianness conversion for me so this just
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
> I would prefer that the virtio API not expose a little endian standard.
> I'm currently converting config->get() ops to ioreadXX depending on the
> size which already does the endianness conversion for me so this just
> messes things up
Rusty Russell wrote:
After discussion with Anthony, the virtio config has been simplified. We
lose some minor features (the virtio_net address must now be 6 bytes) but
it turns out to be a wash in terms of complexity, while simplifying PCI.
Hi Rusty,
Thanks for posting this! It's really s
After discussion with Anthony, the virtio config has been simplified. We
lose some minor features (the virtio_net address must now be 6 bytes) but
it turns out to be a wash in terms of complexity, while simplifying PCI.
This can be found in the new virtio git tree, in the "patches/1" branch
(new
13 matches
Mail list logo
