[PULL] virtio
The following changes since commit 925a6f0bf8bd122d5d2429af7f0ca0fecf4ae71f: Merge tag 'hwspinlock-3.6-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock (2012-09-18 11:58:54 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git virtio-next for you to fetch changes up to ca16f580a5db7e60bfafe59a50bb133bd3347491: lguest: fix occasional crash in example launcher. (2012-10-04 12:12:59 +0930) New workflow: same git trees pulled by linux-next get sent straight to Linus. Git is awkward at shuffling patches compared with quilt or mq, but that doesn't happen often once things get into my -next branch. Alexey Khoroshilov (1): virtio: console: fix error handling in init() function Asias He (3): virtio-blk: Add bio-based IO path for virtio-blk virtio-blk: Add REQ_FLUSH and REQ_FUA support to bio path virtio-blk: Disable callback in virtblk_done() Brian Foley (2): virtio_mmio: fix off by one error allocating queue virtio_mmio: Don't attempt to create empty virtqueues Dan Carpenter (1): virtio-blk: fix NULL checking in virtblk_alloc_req() Jason Wang (2): virtio-ring: move queue_index to vring_virtqueue virtio: introduce an API to set affinity for a virtqueue Masami Hiramatsu (5): virtio/console: Add splice_write support virtio/console: Add a failback for unstealable pipe buffer virtio/console: Wait until the port is ready on splice ftrace: Allow stealing pages from pipe buffer virtio/console: Allocate scatterlist according to the current pipe size Michael S. Tsirkin (3): virtio-balloon: dependency fix virtio: support reserved vqs virtio: don't crash when device is buggy Peter Senna Tschudin (1): drivers/virtio/virtio_pci.c: fix error return code Rusty Russell (4): virtio_balloon: not EXPERIMENTAL any more. virtio: add help to CONFIG_VIRTIO option. virtio: remove CONFIG_VIRTIO_RING lguest: fix occasional crash in example launcher. Yoshihiro YUNOMAE (2): tools: Add guest trace agent as a user tool tools: Fix pthread flag for Makefile of trace-agent used by virtio-trace arch/s390/Kconfig |1 - arch/x86/lguest/Kconfig |1 - drivers/block/virtio_blk.c | 306 +++ drivers/char/virtio_console.c | 210 -- drivers/lguest/lguest_device.c |5 +- drivers/remoteproc/remoteproc_virtio.c |5 +- drivers/rpmsg/Kconfig |1 - drivers/s390/kvm/kvm_virtio.c |5 +- drivers/virtio/Kconfig | 17 +- drivers/virtio/Makefile |3 +- drivers/virtio/virtio.c |2 +- drivers/virtio/virtio_mmio.c| 29 ++- drivers/virtio/virtio_pci.c | 68 +- drivers/virtio/virtio_ring.c| 14 +- include/linux/virtio.h |2 + include/linux/virtio_config.h | 23 ++ include/linux/virtio_ring.h |3 +- kernel/trace/trace.c|8 +- tools/lguest/lguest.c |1 + tools/virtio/virtio-trace/Makefile | 13 ++ tools/virtio/virtio-trace/README| 118 +++ tools/virtio/virtio-trace/trace-agent-ctl.c | 137 tools/virtio/virtio-trace/trace-agent-rw.c | 192 + tools/virtio/virtio-trace/trace-agent.c | 270 +++ tools/virtio/virtio-trace/trace-agent.h | 75 +++ 25 files changed, 1402 insertions(+), 107 deletions(-) create mode 100644 tools/virtio/virtio-trace/Makefile create mode 100644 tools/virtio/virtio-trace/README create mode 100644 tools/virtio/virtio-trace/trace-agent-ctl.c create mode 100644 tools/virtio/virtio-trace/trace-agent-rw.c create mode 100644 tools/virtio/virtio-trace/trace-agent.c create mode 100644 tools/virtio/virtio-trace/trace-agent.h ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Proposal for virtio standardization.
Rusty Russell writes: > Hi all, > > I've had several requests for a more formal approach to the > virtio draft spec, and (after some soul-searching) I'd like to try that. > > The proposal is to use OASIS as the standards body, as it's > fairly light-weight as these things go. For me this means paperwork and > setting up a Working Group and getting the right people involved as > Voting members starting with the current contributors; for most of you > it just means a new mailing list, though I'll be cross-posting any > drafts and major changes here anyway. > > I believe that a documented standard (aka virtio 1.0) will > increase visibility and adoption in areas outside our normal linux/kvm > universe. There's been some of that already, but this is the clearest > path to accelerate it. Not the easiest path, but I believe that a solid > I/O standard is a Good Thing for everyone. > > Yet I also want to decouple new and experimental development > from the standards effort; running code comes first. New feature bits > and new device numbers should be reservable without requiring a full > spec change. > > So the essence of my proposal is: > 1) I start a Working Group within OASIS where we can aim for virtio spec >1.0. > > 2) The current spec is textually reordered so the core is clearly >bus-independent, with PCI, mmio, etc appendices. > > 3) Various clarifications, formalizations and cleanups to the spec text, >and possibly elimination of old deprecated features. > > 4) The only significant change to the spec is that we use PCI >capabilities, so we can have infinite feature bits. >(see > http://lists.linuxfoundation.org/pipermail/virtualization/2011-December/019198.html) We discussed this on IRC last night. I don't think PCI capabilites are a good mechanism to use... PCI capabilities are there to organize how the PCI config space is allocated to allow vendor extensions to co-exist with future PCI extensions. But we've never used the PCI config space within virtio-pci. We do everything in BAR0. I don't think there's any real advantage of using the config space vs. a BAR for virtio-pci. The nice thing about using a BAR is that the region is MMIO or PIO. This maps really nicely to non-PCI transports too. But extending the PCI config space (especially dealing with capability allocation) is pretty gnarly and there isn't an obvious equivalent outside of PCI. There are very devices that we emulate today that make use of extended PCI device registers outside the platform devices (that have no BARs). Regards, Anthony Liguori > > 5) Changes to the ring layout and other such things are deferred to a >future virtio version; whether this is done within OASIS or >externally depends on how well this works for the 1.0 release. > > Thoughts? > Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/3] virtio-net: inline header support
Il 04/10/2012 14:51, Rusty Russell ha scritto:
> Paolo Bonzini writes:
>
>> Il 04/10/2012 02:11, Rusty Russell ha scritto:
> There's a reason I haven't done this. I really, really dislike "my
> implemention isn't broken" feature bits. We could have an infinite
> number of them, for each bug in each device.
However, this bug affects (almost) all implementations and (almost) all
devices. It even makes sense to reserve a transport feature bit for it
instead of a device feature bit.
>>>
>>> Perhaps, but we have to fix the bugs first!
>>
>> Yes. :) Isn't that what mst's patch does?
>>
>>> As I said, my torture patch broke qemu immediately. Since noone has
>>> leapt onto fixing that, I'll take a look now...
>>
>> I can look at virtio-scsi.
>
> Actually, you can't, see my reply to Anthony...
>
> Message-ID: <87lifm1y1n@rustcorp.com.au>
struct virtio_scsi_req_cmd {
// Read-only
u8 lun[8];
u64 id;
u8 task_attr;
u8 prio;
u8 crn;
char cdb[cdb_size];
char dataout[];
// Write-only part
u32 sense_len;
u32 residual;
u16 status_qualifier;
u8 status;
u8 response;
u8 sense[sense_size];
char datain[];
};
where cdb_size and sense_size come from configuration space. The device
right now expects everything before dataout/datain to be in a single
descriptor, but that's in no way part of the spec. Am I missing
something egregious?
Paolo
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/3] virtio-net: inline header support
Paolo Bonzini writes: > Il 04/10/2012 02:11, Rusty Russell ha scritto: >> > > There's a reason I haven't done this. I really, really dislike "my >> > > implemention isn't broken" feature bits. We could have an infinite >> > > number of them, for each bug in each device. >> > >> > However, this bug affects (almost) all implementations and (almost) all >> > devices. It even makes sense to reserve a transport feature bit for it >> > instead of a device feature bit. >> >> Perhaps, but we have to fix the bugs first! > > Yes. :) Isn't that what mst's patch does? > >> As I said, my torture patch broke qemu immediately. Since noone has >> leapt onto fixing that, I'll take a look now... > > I can look at virtio-scsi. Actually, you can't, see my reply to Anthony... Message-ID: <87lifm1y1n@rustcorp.com.au> Cheers, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/3] virtio-net: inline header support
Anthony Liguori writes: >> lguest fix is pending in my queue. lkvm and qemu are broken; lkvm isn't >> ever going to be merged, so I'm not sure what its status is? But I'm >> determined to fix qemu, and hence my torture patch to make sure this >> doesn't creep in again. > > There are even more implementations out there and I'd wager they all > rely on framing. Worse, both virtio_blk (for scsi commands) and virtio_scsi explicitly and inescapably rely on framing. The spec conflicts clearly with itself. Such layering violations are always a mistake, but I can't blame anyone else for my lack of attention :( Here's the spec change: commit 7e74459bb966ccbaad9e4bf361d1178b7f400b79 Author: Rusty Russell Date: Thu Oct 4 17:11:27 2012 +0930 No longer assume framing is independent of messages. *sniff* Signed-off-by: Rusty Russell --- virtio-spec.txt 2012-10-04 17:13:04.988259234 +0930 +++ virtio-spec.txt.new 2012-10-04 17:12:54.624258969 +0930 @@ -880,19 +880,19 @@ Message Framing -The descriptors used for a buffer should not effect the semantics -of the message, except for the total length of the buffer. For -example, a network buffer consists of a 10 byte header followed -by the network packet. Whether this is presented in the ring -descriptor chain as (say) a 10 byte buffer and a 1514 byte -buffer, or a single 1524 byte buffer, or even three buffers, -should have no effect. +Unless stated otherwise, it is expected that headers within a +message are contained within their own descriptors. For example, +a network buffer consists of a 10 or 12 byte header followed by +the network packet. An implementation should expect that this +header will be within the first descriptor, and that the +remainder of the data will begin on the second descriptor. -In particular, no implementation should use the descriptor -boundaries to determine the size of any header in a request.[footnote: -The current qemu device implementations mistakenly insist that -the first descriptor cover the header in these cases exactly, so -a cautious driver should arrange it so. +[footnote: +It was previously asserted that framing should be independent of +message contents, yet invariably drivers layed out messages in +reliable ways and devices assumed it. In addition, the +specifications for virtio_blk and virtio_scsi require intuiting +field lengths from frame boundaries. ] Device Improvements ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/3] virtio-net: inline header support
Il 04/10/2012 02:11, Rusty Russell ha scritto: > > > There's a reason I haven't done this. I really, really dislike "my > > > implemention isn't broken" feature bits. We could have an infinite > > > number of them, for each bug in each device. > > > > However, this bug affects (almost) all implementations and (almost) all > > devices. It even makes sense to reserve a transport feature bit for it > > instead of a device feature bit. > > Perhaps, but we have to fix the bugs first! Yes. :) Isn't that what mst's patch does? > As I said, my torture patch broke qemu immediately. Since noone has > leapt onto fixing that, I'll take a look now... I can look at virtio-scsi. Paolo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
