On Tue, 22 Jun 2010 02:13:21 am Ryan Harper wrote:
* john cooper john.coo...@redhat.com [2010-06-21 01:11]:
Rusty Russell wrote:
On Sat, 19 Jun 2010 04:08:02 am Ryan Harper wrote:
Create a new attribute for virtio-blk devices that will fetch the serial
number
of the block device
On Thu, 24 Jun 2010 12:49:56 pm Ryan Harper wrote:
Using Rusty's suggestion I've respun the patch removing the special copy
function. I've tested this patch in a guest kernel with and without qemu
supplying serial numbers for the block devices and it's working as expected.
When qemu supplies
On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote:
On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Shouldn't it be possible to just drop the lock before invoking
virtqueue_kick() and reacquire it afterwards? There's nothing in that
virtqueue_kick() path
On Thu, 24 Dec 2009 04:30:58 pm Michael S. Tsirkin wrote:
This fixes two issues with recent access checking patch:
1. if (d-vqs[i].private_data) - if (d-vqs[i].private_data)
2. we can't forbid log base changes while ring is running,
because host needs to resize log in rare cases
On Tue, 29 Dec 2009 03:09:23 am Avi Kivity wrote:
This patch adds a physical block size attribute to virtio disks,
corresponding to /sys/devices/.../physical_block_size. It is defined as
the request alignment which will not trigger RMW cycles. This can be
important for modern disks which use
On Thu, 14 Jan 2010 07:23:38 am Shirley Ma wrote:
virtio_net receives packets from its pre-allocated vring buffers, then it
delivers these packets to upper layer protocols as skb buffs. So it's not
necessary to pre-allocate skb for each mergable buffer, then frees extra
skbs when buffers are
cc: net...@vger.kernel.org for net patches...
Your comment could be slightly enhanced to indicate that the API is new, eg;
Now we have a virtio detach API (in commit XX), we don't need to
track xmit skbs in the driver.
Acked-by: Rusty Russell ru...@rustcorp.com.au
Thanks
On Wed, 10 Feb 2010 11:30:39 pm Michael S. Tsirkin wrote:
Add documentation for indirect descriptors
Thanks, that's awesome!
I added an entry to the Reserved Feature table in appendix B, and applied
it. We're now at 0.8.5.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line
On Fri, 12 Feb 2010 03:52:36 am Michael S. Tsirkin wrote:
This documents MSI-X support in virtio.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Wow, great!
I reworked one paragraph for better grammar. Mainly adding the:
(pseudo-patch):
Devices report such failures by returning
...@redhat.com
Acked-by: Rusty Russell ru...@rustcorp.com.au
Thanks!
Rusty.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 30 Oct 2010 01:29:33 pm Simon Horman wrote:
[ CCed VHOST contacts ]
On Thu, Oct 28, 2010 at 01:22:02PM -0700, Jesse Gross wrote:
On Thu, Oct 28, 2010 at 4:54 AM, Simon Horman ho...@verge.net.au wrote:
My reasoning is that in the non-mirroring case the guest is
limited by the
On Thu, 11 Nov 2010 01:38:23 am Michael S. Tsirkin wrote:
On Mon, Nov 08, 2010 at 09:41:27AM +1030, Rusty Russell wrote:
On Fri, 5 Nov 2010 08:17:18 pm Jason Wang wrote:
For device that supports VIRTIO_NET_F_STATUS, there's no need to
assume the link is up and we need to call
On Tue, 30 Nov 2010 03:46:37 am Michael S. Tsirkin wrote:
This is the userspace part of the tool: it includes a bunch of stubs for
linux APIs, somewhat simular to linuxsched. This makes it possible to
recompile the ring code in userspace.
A small test example is implemented combining this
On Tue, 14 Dec 2010 03:54:47 am Michael S. Tsirkin wrote:
On Mon, Dec 13, 2010 at 12:44:13PM +0200, Michael S. Tsirkin wrote:
Please merge the following tree for 2.6.38.
Thanks!
Um, I sent this out before I noticed the mail from Rusty
with some questions on the test code. I missed that
On Mon, 17 Jan 2011 09:07:30 am Simon Horman wrote:
[snip]
I've been away, but what concerns me is that socket buffer limits are
bypassed in various configurations, due to skb cloning. We should probably
drop such limits altogether, or fix them to be consistent.
Simple fix is as someone
On Thursday 08 January 2009 04:36:02 Alex Williamson wrote:
virtio_net: Enable setting MAC, promisc, and allmulti mode
Hi Alex,
There's nothing wrong with this idea: I assume you have an actual usage
for this rather than it being an abstract improvement?
@@ -41,7 +41,14 @@ struct
On Thursday 08 January 2009 04:36:03 Alex Williamson wrote:
virtio_net: Add MAC fitler table support
Ah, I see. You really want multiple mac addresses, not just multicast
filtering?
Anthony, you think a control channel? We can add a virtqueue, but it seems
like a lot of work...
Rusty.
--
To
On Tuesday 27 January 2009 14:08:02 Alex Williamson wrote:
Hi Rusty,
On Tue, 2009-01-27 at 13:00 +1030, Rusty Russell wrote:
On Saturday 17 January 2009 07:43:34 Alex Williamson wrote:
As with most real hardware, unicast addresses have priority in
the filter table so we can avoid
On Tuesday 27 January 2009 14:30:06 Alex Williamson wrote:
Hi Rusty,
On Tue, 2009-01-27 at 13:52 +1030, Rusty Russell wrote:
On Saturday 17 January 2009 07:43:23 Alex Williamson wrote:
+ return status ? -EFAULT : 0;
This is wrong. Currently this can't happen, right? But you put
On Thursday 29 January 2009 04:18:28 Alex Williamson wrote:
Hi Rusty,
Hi Alex,
I've cc'd Herbert: he always has good thoughts about this kind of thing and
I want to be sure you're getting a fair hearing.
Here's what I believe to be the parameters around which I've designed
the current
On Thursday 29 January 2009 05:32:21 Alex Williamson wrote:
On Wed, 2009-01-28 at 23:35 +1030, Rusty Russell wrote:
On Tuesday 27 January 2009 14:30:06 Alex Williamson wrote:
On Tue, 2009-01-27 at 13:52 +1030, Rusty Russell wrote:
If we're sure they never want to see the value, then we
On Friday 30 January 2009 09:35:02 Alex Williamson wrote:
I'm not completely sure it's everything
you're looking for Rusty, but it does seem cleaner. Let me know if
this is closer to what you're thinking.
Yep, now I'll go through the patches more carefully.
I know it's a pain to get this
On Friday 30 January 2009 09:35:07 Alex Williamson wrote:
+static bool virtnet_send_command(struct virtnet_info *vi, u8 class, u8 cmd,
+ void *data, unsigned int len)
+{
+ struct scatterlist sg[3];
+ struct virtio_net_ctrl_hdr ctrl;
+
On Friday 30 January 2009 09:35:12 Alex Williamson wrote:
+static void virtnet_set_rx_mode(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ u8 promisc, allmulti;
+
+ if (!virtio_has_feature(vi-vdev, VIRTIO_NET_F_CTRL_RX))
+ return;
Hmm,
On Friday 30 January 2009 09:35:18 Alex Williamson wrote:
struct virtnet_info *vi = netdev_priv(dev);
u8 promisc, allmulti;
+ struct scatterlist sg[4];
+ struct virtio_net_ctrl_hdr ctrl;
+ virtio_net_ctrl_ack status;
+ u8 *uc_buf = NULL, *mc_buf = NULL;
+
On Friday 30 January 2009 09:35:23 Alex Williamson wrote:
+ if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_VLAN,
+ VIRTIO_NET_CTRL_VLAN_ADD, vid, sizeof(vid)))
+ printk(KERN_WARNING %s: Failed to add VLAN ID %d.\n,
+dev-name,
On Friday 30 January 2009 12:19:13 David Miller wrote:
From: Alex Williamson alex.william...@hp.com
Date: Thu, 29 Jan 2009 16:05:02 -0700
I'm not completely sure it's everything you're looking for Rusty,
but it does seem cleaner. Let me know if this is closer to what
you're thinking.
of virtnet_send_command).
Thanks,
Rusty.
PS. Oh, this actual patch was fine: Acked-by: Rusty Russell
ru...@rustcorp.com.au
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Monday 02 February 2009 06:35:20 Alex Williamson wrote:
+ * In addition to the class/cmd header, the TABLE_SET command requires
+ * two out scatterlists. Each contains a 4 byte count of entries followed
+ * by a concatenated byte stream of the ETH_ALEN MAC addresses. The
+ * first sg list
, this is really an internal issue, no?
Other than that, you can add Acked-by: Rusty Russell ru...@rustcorp.com.au
and send to netdev for DaveM's tree.
Thanks!
Rusty.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Tuesday 03 February 2009 08:04:07 Alex Williamson wrote:
Hi Rusty,
On Mon, 2009-02-02 at 20:22 +1030, Rusty Russell wrote:
static bool virtnet_send_command(struct virtnet_info *vi, u8 class, u8
cmd,
struct scatterlist *out, struct scatterlist
On Wednesday 04 February 2009 09:36:36 David Miller wrote:
The second patch doesn't apply to the net-next-2.6 tree.
Please regenerate these against net-next-2.6 or -next and
I'll apply them, thanks.
And FWIW:
Acked-by: Rusty Russell ru...@rustcorp.com.au
Thanks!
Rusty.
--
To unsubscribe
On Thursday 05 February 2009 05:56:06 Alex Williamson wrote:
Many physical NICs let the OS re-program the hardware MAC
address. Virtual NICs should allow this too.
Signed-off-by: Alex Williamson alex.william...@hp.com
Acked-by: Mark McLoughlin mar...@redhat.com
---
Rusty, you've already
On Thursday 19 February 2009 02:54:06 Arnd Bergmann wrote:
On Wednesday 18 February 2009, Rusty Russell wrote:
2) Direct NIC attachment
This is particularly interesting with SR-IOV or other multiqueue nics,
but for boutique cases or benchmarks, could be for normal NICs. So
far I have
On Thursday 19 February 2009 10:01:42 Simon Horman wrote:
On Wed, Feb 18, 2009 at 10:08:00PM +1030, Rusty Russell wrote:
2) Direct NIC attachment This is particularly interesting with SR-IOV or
other multiqueue nics, but for boutique cases or benchmarks, could be for
normal NICs. So far
On Wednesday 01 April 2009 05:12:47 Gregory Haskins wrote:
Bare metal: tput = 4078Mb/s, round-trip = 25593pps (39us rtt)
Virtio-net: tput = 4003Mb/s, round-trip = 320pps (3125us rtt)
Venet: tput = 4050Mb/s, round-trip = 15255 (65us rtt)
That rtt time is awful. I know the notification
On Wednesday 01 April 2009 22:05:39 Gregory Haskins wrote:
Rusty Russell wrote:
I could dig through the code, but I'll ask directly: what heuristic do
you use for notification prevention in your venet_tap driver?
I am not 100% sure I know what you mean with notification prevention
On Thursday 02 April 2009 21:36:07 Gregory Haskins wrote:
You do not need to know when the packet is copied (which I currently
do). You only need it for zero-copy (of which I would like to support,
but as I understand it there are problems with the reliability of proper
callback (i.e.
On Thursday 02 April 2009 02:40:29 Anthony Liguori wrote:
Rusty Russell wrote:
As you point out, 350-450 is possible, which is still bad, and it's at least
partially caused by the exit to userspace and two system calls. If
virtio_net
had a backend in the kernel, we'd be able to compare
On Tuesday 07 April 2009 00:49:17 Tomasz Chmielewski wrote:
Tomasz Chmielewski schrieb:
As I mentioned, it was using virtio net.
Guests running with e1000 (and virtio_blk) don't have this problem.
Also, virtio_console seem to be affected by this slowness issue.
I'm pretty sure this
On Sun, 26 Apr 2009 10:19:16 pm Avi Kivity wrote:
Pantelis Koukousoulas wrote:
Please copy the virtio maintainer (Rusty Russell ru...@rustcorp.com.au)
on
virtio guest patches.
Well, for now the issue is whether my understanding of qemu/pci-ids.txt and
the
comment
On Wed, 8 Sep 2010 04:59:05 pm Krishna Kumar wrote:
Add virtio_get_queue_index() to get the queue index of a
vq. This is needed by the cb handler to locate the queue
that should be processed.
This seems a bit weird. I mean, the driver used vdev-config-find_vqs
to find the queues, which
On Thu, 9 Sep 2010 11:19:33 pm Krishna Kumar2 wrote:
Rusty Russell ru...@rustcorp.com.au wrote on 09/09/2010 05:44:25 PM:
Ah, good point. Move the queue index into the struct virtqueue?
Is it OK to move the queue_index from virtio_pci_vq_info
to virtqueue? I didn't want to change any data
On Sun, 12 Sep 2010 06:30:43 pm Avi Kivity wrote:
On 09/12/2010 02:42 AM, Alexander Graf wrote:
On 24.08.2010, at 15:48, Alexander Graf wrote:
The one big missing feature in s390-virtio was hotplugging. This is no
more.
This patch implements hotplug add support, so you can on the fly
On Wed, 15 Sep 2010 11:16:24 pm Amit Shah wrote:
On (Wed) Sep 15 2010 [15:37:21], Hans de Goede wrote:
--- linux-2.6.35.x86_64/drivers/char/virtio_console.c~2010-08-02
00:11:14.0 +0200
+++ linux-2.6.35.x86_64/drivers/char/virtio_console.c 2010-09-15
13:39:29.043505000
On Tue, 5 Oct 2010 11:15:21 pm Dave Young wrote:
Balloon could cause guest memory oom killing and panic.
Add oom notify to leak some memory and retry fill balloon after 5 minutes.
Have you tried registering a shrinker? See mm.h.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line
and/or Christoph please
review/advise.
Thanks, applied, and CC'd sta...@kernel.org (it's in 2.6.35 as well).
From: Mike Snitzer snit...@redhat.com
Subject: virtio-blk: fix request leak.
Must drop reference taken by blk_make_request().
Signed-off-by: Mike Snitzer snit...@redhat.com
Signed-off-by: Rusty
Rusty Russell ru...@rustcorp.com.au writes:
Jamie Lokier ja...@shareable.org writes:
Rusty Russell wrote:
I don't think it'll be that bad; reset clears the device to unknown,
bar0 moves it from unknown-legacy mode, bar1/2/3 changes it from
unknown-modern mode, and anything else is bad (I
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Oct 10, 2012 at 08:36:12AM -0500, Anthony Liguori wrote:
Rusty Russell ru...@rustcorp.com.au writes:
Gerd Hoffmann kra...@redhat.com writes:
So how about this:
(1) Add a vendor specific pci capability for new-style virtio
Paolo Bonzini pbonz...@redhat.com writes:
Il 09/10/2012 06:59, Rusty Russell ha scritto:
Paolo Bonzini pbonz...@redhat.com writes:
Il 05/10/2012 07:43, Rusty Russell ha scritto:
That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
said to Anthony, the best rules are always
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Oct 08, 2012 at 12:51:25PM +1030, Rusty Russell wrote:
Note before anyone gets confused; we were talking about using the PCI
config space to indicate what BAR(s) the virtio stuff is in. An
alternative would be to simply specify a new layout
Christoffer Dall c.d...@virtualopensystems.com writes:
On Tue, Oct 9, 2012 at 2:11 PM, Peter Maydell peter.mayd...@linaro.org
wrote:
On 1 October 2012 10:11, Christoffer Dall c.d...@virtualopensystems.com
wrote:
From: Rusty Russell rusty.russ...@linaro.org
...
+ARM 32-bit VFP control
Marcelo Tosatti mtosa...@redhat.com writes:
On Wed, Sep 05, 2012 at 05:28:46PM +0930, Rusty Russell wrote:
...
+struct kvm_reg_list {
+__u64 n; /* number of registers in reg[] */
+__u64 reg[0];
+};
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 169a001..453fe93 100644
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Oct 11, 2012 at 11:48:22AM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Oct 08, 2012 at 12:51:25PM +1030, Rusty Russell wrote:
Note before anyone gets confused; we were talking about using the PCI
config
Paolo Bonzini pbonz...@redhat.com writes:
Il 11/10/2012 08:41, Bryan Venteicher ha scritto:
This is analogous to commit a1b383870a made by Rusty Russell to all
the VirtIO headers at the time. This eases the use of the header as
is by other OSes.
Signed-off-by: Bryan Venteicher bry
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
OK. Well, Anthony wants qemu to be robust in this regard, so I am
tempted to rework all the qemu drivers to handle arbitrary layouts.
They could use a good audit anyway.
I agree here
Michael S. Tsirkin m...@redhat.com writes:
On Fri, Oct 12, 2012 at 08:21:50PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote:
For writes, the standard seems to be a commit latch. We could abuse
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Oct 16, 2012 at 11:45:41PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
I was assuming the implementation would keep two complete copies of the
config space: writes go to the scratch version, which gets copied
Asias He as...@redhat.com writes:
+#define BLK_HDR0
What's this for, exactly? Please add a comment.
The block headr is in the first and separate buffer.
Please don't assume this! We're trying to fix all the assumptions in
qemu at the moment.
vhost_net handles this correctly, taking
Avi Kivity a...@redhat.com writes:
On 09/05/2012 10:58 AM, Rusty Russell wrote:
This is the generic part of the KVM_SET_ONE_REG/KVM_GET_ONE_REG
enhancements which ARM wants, rebased onto kvm/next.
This was stalled for so long it needs rebasing again, sorry.
But otherwise I'm happy to apply
Rusty Russell ru...@rustcorp.com.au writes:
Avi Kivity a...@redhat.com writes:
On 09/05/2012 10:58 AM, Rusty Russell wrote:
This is the generic part of the KVM_SET_ONE_REG/KVM_GET_ONE_REG
enhancements which ARM wants, rebased onto kvm/next.
This was stalled for so long it needs rebasing
Christoffer Dall c.d...@virtualopensystems.com writes:
On Fri, Oct 19, 2012 at 2:19 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Wait, what? kvm/arm isn't in kvm-next?
Christoffer, is there anything I can help with?
Specifically there are worries about the instruction decoding
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Oct 18, 2012 at 02:50:56PM +1030, Rusty Russell wrote:
Asias He as...@redhat.com writes:
+#define BLK_HDR 0
What's this for, exactly? Please add a comment.
The block headr is in the first and separate buffer.
Please don't assume
From: Rusty Russell rusty.russ...@linaro.org
We add some callbacks and use them instead of using struct kvm_vcpu or
vcpu_reg() directly. We also remove the kvm_ prefixes, and call the
top-level function decode_insn() instead of kvm_decode().
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
From: Rusty Russell rusty.russ...@linaro.org
For generic code we won't know the hdfar, so make the offset_addr relative
in thumb mode.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff
From: Rusty Russell rusty.russ...@linaro.org
We need the C bit, so hand down the psr through the callchain.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/arm
From: Rusty Russell rusty.russ...@linaro.org
Now we put instr inside struct arm_insn, we don't need to hand it
internally.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c | 100 ++--
1 file changed, 45 insertions
From: Rusty Russell rusty.russ...@linaro.org
Now we simply call kvm_decode_ls(), and if it succeeds, execute() to
handle the instruction.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c | 131 ++--
1 file changed, 70
From: Rusty Russell rusty.russ...@linaro.org
We determine whether we're in thumb mode and whether it's a wide instruction
when we copy it in, so just initialize is_thumb and is_thumb32 there.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c | 44
From: Rusty Russell rusty.russ...@linaro.org
Add thumb info to struct arm_insn, and use that to store decode
information for later handling in execute_thumb().
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c | 120
From: Rusty Russell rusty.russ...@linaro.org
This adds more fields which we need to store in the struct arm_insn,
so execute() knows what to do.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c | 80 ++--
1 file
From: Rusty Russell rusty.russ...@linaro.org
Add a new 'struct arm_insn' to represent the decoded instruction; the
decoding logic belong in a separate structure (arm_decode).
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/arm/kvm/emulate.c | 120
Compile-tested only, but shows what it looks like (ugly).
I just used the existing code and didn't crack open my ARM books to
determine if there's a better way. The struct names are pretty vague,
too, as a result.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
Stephen Rothwell s...@canb.auug.org.au writes:
Hi Rusty,
On Tue, 02 Oct 2012 15:56:56 +0930 Rusty Russell ru...@rustcorp.com.au
wrote:
Please remove my quilt tree
http://ozlabs.org/~rusty/kernel/rr-latest/ from linux-next, and use my
git trees from now on:
git://git.kernel.org
Jason Wang jasow...@redhat.com writes:
This patch implement the {set|get}_channels method of ethool to allow user to
change the number of queues dymaically when the device is running. This would
let the user to tune the device for specific applications.
...
+ /* Only two modes were support
Jason Wang jasow...@redhat.com writes:
This addes multiqueue support to virtio_net driver. There's two mode
supported:
single queue pair mode and multiple queue pairs mode. An obvious
difference compared with a physical mq card is that virtio-net reserve
first two virtqueues when it is
Jason Wang jasow...@redhat.com writes:
+struct virtnet_info {
+ u16 num_queue_pairs;/* # of RX/TX vq pairs */
+ u16 total_queue_pairs;
+
+ struct send_queue *sq;
+ struct receive_queue *rq;
+ struct virtqueue *cvq;
+
+ struct virtio_device *vdev;
+
Asias He as...@redhat.com writes:
vhost-blk is an in-kernel virito-blk device accelerator.
Due to lack of proper in-kernel AIO interface, this version converts
guest's I/O request to bio and use submit_bio() to submit I/O directly.
So this version any supports raw block device as guest's disk
Peter Maydell peter.mayd...@linaro.org writes:
On 19 November 2012 15:01, Will Deacon will.dea...@arm.com wrote:
On Sat, Nov 10, 2012 at 03:43:13PM +, Christoffer Dall wrote:
+/*
+ * A15-specific CP15 registers.
+ * Important: Must be sorted ascending by CRn, CRM, Op1, Op2
+ */
+static
Michael S. Tsirkin m...@redhat.com writes:
Add RFS support to virtio network device.
Add a new feature flag VIRTIO_NET_F_RFS for this feature, a new
configuration field max_virtqueue_pairs to detect supported number of
virtqueues as well as a new command VIRTIO_NET_CTRL_RFS to program
packet
Jason Wang jasow...@redhat.com writes:
+static const struct ethtool_ops virtnet_ethtool_ops;
+
+/*
+ * Converting between virtqueue no. and kernel tx/rx queue no.
+ * 0:rx0 1:tx0 2:cvq 3:rx1 4:tx1 ... 2N+1:rxN 2N+2:txN
+ */
+static int vq2txq(struct virtqueue *vq)
+{
+ int index =
Jason Wang jasow...@redhat.com writes:
To support multiqueue transmitq/receiveq, the first step is to separate queue
related structure from virtnet_info. This patch introduce send_queue and
receive_queue structure and use the pointer to them as the parameter in
functions handling
Peter Maydell peter.mayd...@linaro.org writes:
On 3 December 2012 10:36, Dong Aisheng b29...@freescale.com wrote:
and via current ONE_REG interface we do not know which CPU
is performing the register access, so the banked registers are not
suppported well,
Actually you do, because it's a
Jason Wang jasow...@redhat.com writes:
On Monday, December 03, 2012 12:25:42 PM Rusty Russell wrote:
+
+ /* Work struct for refilling if we run low on memory. */
+ struct delayed_work refill;
I can't really see the justificaiton for a refill per queue. Just have
one work iterate all
Ben Hutchings bhutchi...@solarflare.com writes:
If you want a name for the whole set of
features involved, I don't see any better name than 'multiqueue'/'MQ'.
OK, let's go back to multiqueue then, and perhaps refer to the current
receive steering as 'automatic'.
Cheers,
Rusty.
--
To
Michael S. Tsirkin m...@redhat.com writes:
Add multiqueue support to virtio network device.
Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new
configuration field max_virtqueue_pairs to detect supported number of
virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program
Michael S. Tsirkin m...@redhat.com writes:
Add multiqueue support to virtio network device.
Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new
configuration field max_virtqueue_pairs to detect supported number of
virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program
Alexander Graf ag...@suse.de writes:
When a file system is mounted on a virtio-blk disk, we then remove it
and then reattach it, the reattached disk gets the same disk name and
ids as the hot removed one.
This leads to very nasty effects - mostly rendering the newly attached
device
interface is pretty
nasty; I think I'd prefer the chained scatterlists, if that's optimal
for you.
Cheers,
Rusty.
From: Rusty Russell ru...@rustcorp.com.au
Subject: virtio: use chained scatterlists.
Rather than handing a scatterlist[] and out and in numbers to
virtqueue_add_buf(), hand two
Alexander Graf ag...@suse.de writes:
On 20.12.2012, at 09:46, Asias He as...@redhat.com wrote:
On 12/20/2012 12:15 PM, Rusty Russell wrote:
Alexander Graf ag...@suse.de writes:
When a file system is mounted on a virtio-blk disk, we then remove it
and then reattach it, the reattached disk
Wanlong Gao gaowanl...@cn.fujitsu.com writes:
On 01/02/2013 01:03 PM, Rusty Russell wrote:
Paolo Bonzini pbonz...@redhat.com writes:
The virtqueue_add_buf function has two limitations:
1) it requires the caller to provide all the buffers in a single call;
2) it does not support chained
Paolo Bonzini pbonz...@redhat.com writes:
Il 02/01/2013 06:03, Rusty Russell ha scritto:
Paolo Bonzini pbonz...@redhat.com writes:
The virtqueue_add_buf function has two limitations:
1) it requires the caller to provide all the buffers in a single call;
2) it does not support chained
On Sun, 3 Jul 2011 15:11:37 +0300, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Jul 03, 2011 at 01:52:29PM +0300, Sasha Levin wrote:
This just leads me to believe that we should either not notify the host,
or not wait_for_completion() when telling the host.
Interesting. The spec says
On Sat, 13 Aug 2011 11:51:01 +0300, Sasha Levin levinsasha...@gmail.com wrote:
The MAC of a virtio-net device is located at the first field of the device
specific header. This header is located at offset 20 if the device doesn't
support MSI-X or offset 24 if it does.
Erk. This means, in
On Sun, 14 Aug 2011 16:57:32 +0300, Sasha Levin levinsasha...@gmail.com wrote:
On Sun, 2011-08-14 at 12:23 +0930, Rusty Russell wrote:
On Sat, 13 Aug 2011 11:51:01 +0300, Sasha Levin levinsasha...@gmail.com
wrote:
The MAC of a virtio-net device is located at the first field of the device
of whether MSI-X is
enabled. This way the MAC will be read from offset 24 if the device indeed
supports MSI-X.
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Michael S. Tsirkin m...@redhat.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Cc: kvm@vger.kernel.org
On Mon, 22 Aug 2011 11:36:13 +0300, Michael S. Tsirkin m...@redhat.com
wrote:
Yes. Or maybe 'WHEN' - since if MSI-X is disabled again, it moves back.
Let's update the spec to make it clearer?
I left the language as is, but added a footnote at the end of the
sentence:
If MSI-X is enabled for
On Tue, 7 Aug 2012 16:52:47 +0200, Cornelia Huck cornelia.h...@de.ibm.com
wrote:
Add a driver for kvm guests that matches virtual ccw devices provided
by the host as virtio bridge devices.
Hi Cornelia,
OK, this is a good opportunity to fix some limitations, just as
we did for
On Mon, 13 Aug 2012 10:56:38 +0200, Cornelia Huck cornelia.h...@de.ibm.com
wrote:
On Wed, 08 Aug 2012 13:52:57 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
On Tue, 7 Aug 2012 16:52:47 +0200, Cornelia Huck
cornelia.h...@de.ibm.com wrote:
1) Please don't limit yourself to 32 feature
On Tue, 14 Aug 2012 13:03:34 +0200, Cornelia Huck cornelia.h...@de.ibm.com
wrote:
It would be per-machine; per-device would be a bit crazy. We'd
deprecate the old ring format.
There's been no consistent thread on the ideas for a ring change,
unfortunately, but you can find interesting
101 - 200 of 640 matches
Mail list logo
