search for: virtio_blk_inhdr

...prio; + /* Sector (ie. 512 byte offset) */ + uint64_t sector; + /* Where to put reply. */ + uint64_t id; +}; + +#define VIRTIO_BLK_S_OK 0 +#define VIRTIO_BLK_S_IOERR 1 +#define VIRTIO_BLK_S_UNSUPP 2 + +/* This is the first element of the write scatter-gather list */ +struct virtio_blk_inhdr +{ + unsigned char status; +}; + +typedef struct VirtIOBlock +{ + VirtIODevice vdev; + BlockDriverState *bs; +} VirtIOBlock; + +static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev) +{ + return (VirtIOBlock *)vdev; +} + +static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue...

...prio; + /* Sector (ie. 512 byte offset) */ + uint64_t sector; + /* Where to put reply. */ + uint64_t id; +}; + +#define VIRTIO_BLK_S_OK 0 +#define VIRTIO_BLK_S_IOERR 1 +#define VIRTIO_BLK_S_UNSUPP 2 + +/* This is the first element of the write scatter-gather list */ +struct virtio_blk_inhdr +{ + unsigned char status; +}; + +typedef struct VirtIOBlock +{ + VirtIODevice vdev; + BlockDriverState *bs; +} VirtIOBlock; + +static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev) +{ + return (VirtIOBlock *)vdev; +} + +static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue...

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Rusty, Anthony, Dor, I need your brain power :-) On smp guests I have seen a problem with virtio (the version in curent Avi's git) which do not occur on single processor guests: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228! illegal operation: 0001 [#1] Modules linked in: ipv6 CPU: 2 Not tainted Process swapper (pid: 0, task: 000000000f83e038, ksp: 000000000f877d70) Krnl

Rusty, Anthony, Dor, I need your brain power :-) On smp guests I have seen a problem with virtio (the version in curent Avi's git) which do not occur on single processor guests: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228! illegal operation: 0001 [#1] Modules linked in: ipv6 CPU: 2 Not tainted Process swapper (pid: 0, task: 000000000f83e038, ksp: 000000000f877d70) Krnl

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c