On Tue, 14 Aug 2012 14:56:07 -0500, Anthony Liguori aligu...@us.ibm.com wrote:
Cornelia Huck cornelia.h...@de.ibm.com writes:
Add a driver for kvm guests that matches virtual ccw devices provided
by the host as virtio bridge devices.
These virtio-ccw devices use a special set of channel
On Wed, 15 Aug 2012 09:48:44 +0200, Christian Borntraeger
borntrae...@de.ibm.com wrote:
Have you written an appendix for the virtio specification for
virtio-ccw? I think it would be good to include in this series for the
purposes of review.
Might be nice, but don't get fancy about it.
Hi all,
This compiles, completely untested, but it's my attempt to give
Avi (and Alexander) what he asked for in a generic register accessor.
Mingled in these patches is the conversion of the latest KVM ARM code,
which is the first proposed user: by the end, we use these accessors for
Instead of overloading x86's KVM_GET_MSRS/KVM_SET_MSRS. The only basic
difference is that the ids are 64 bit.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
diff --git a/arch/arm/include/asm/kvm.h b/arch/arm/include/asm/kvm.h
index d040a2a..9838456 100644
--- a/arch/arm/include/asm/kvm.h
This trivially replaces the arm-specific KVM_VCPU_GET_MSR_INDEX_LIST.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 209b432..b607f60 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -906,6 +906,5 @@ struct
No structures at all any more.
Note: the encoding of general registers makes sense, but it's not
completely logical so the code is quite messy. It would actually be
far neater to expose the struct kvm_vcpu_regs, and use offsets into
that as the ABI.
Peter?
Signed-off-by: Rusty Russell
indices.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 209b432..b607f60 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -906,7 +906,7 @@ struct kvm_s390_ucas_mapping {
#define KVM_KVMCLOCK_CTRL_IO(KVMIO, 0xad
Avi has indicated that this is the future. For now, make it dependent on
KVM_HAVE_ONE_REG (and define that for PPC and S/390).
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index a29e091..7506652
Peter Maydell peter.mayd...@linaro.org writes:
On 29 August 2012 00:48, Rusty Russell rusty.russ...@linaro.org wrote:
No structures at all any more.
I'm not fussed whether we use structs for the core regs or
not; they're not exactly going to change in future so it's
purely a question
Rusty Russell rusty.russ...@linaro.org writes:
No structures at all any more.
Note: the encoding of general registers makes sense, but it's not
completely logical so the code is quite messy. It would actually be
far neater to expose the struct kvm_vcpu_regs, and use offsets
Peter Maydell peter.mayd...@linaro.org writes:
On 29 August 2012 00:37, Rusty Russell rusty.russ...@linaro.org wrote:
This compiles, completely untested, but it's my attempt to give
Avi (and Alexander) what he asked for in a generic register accessor.
Mingled in these patches
Rusty Russell rusty.russ...@linaro.org writes:
Hi all,
This compiles, completely untested, but it's my attempt to give
Avi (and Alexander) what he asked for in a generic register accessor.
And here's the tested version: see my new onereg-abi branch.
My next step is to demux CSELR
Avi Kivity a...@redhat.com writes:
-Capability: basic
+Capability: KVM_CAP_REG_LIST
Architectures: arm
all
OK, I guess that's to be true in future. Fixed.
Type: vcpu ioctl
-Parameters: struct kvm_msr_list (in/out)
+Parameters: struct kvm_reg_list (in/out)
Returns: 0 on success; -1
Rusty Russell ru...@rustcorp.com.au writes:
Rusty Russell rusty.russ...@linaro.org writes:
Hi all,
This compiles, completely untested, but it's my attempt to give
Avi (and Alexander) what he asked for in a generic register accessor.
And here's the tested version: see my new onereg
Avi Kivity a...@redhat.com writes:
On 09/01/2012 03:35 PM, Rusty Russell wrote:
Passing an address in a struct is pretty bad, since it involves
compatibility wrappers.
Right, some s390 thing.
Err, no, i386 on x86-64, or ppc32 on ppc64, or arm on arm64
Any time you put a pointer
indices.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
Documentation/virtual/kvm/api.txt | 20
include/linux/kvm.h | 12
include/linux/kvm_host.h |5 -
virt/kvm/kvm_main.c | 20
4 files
Useful helper for getting length of register given id.
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
include/linux/kvm.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index d808694..8c3760e 100644
--- a/include/linux/kvm.h
+++ b
This is the generic part of the KVM_SET_ONE_REG/KVM_GET_ONE_REG
enhancements which ARM wants, rebased onto kvm/next.
Rusty Russell (3):
KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code.
KVM: Add KVM_REG_SIZE() helper.
KVM: Add KVM_VCPU_GET_REG_LIST/KVM_CAP_REG_LIST.
Documentation
Avi has indicated that this is the future. For now, make it dependent on
KVM_HAVE_ONE_REG (and define that for PPC and S/390).
Signed-off-by: Rusty Russell rusty.russ...@linaro.org
---
arch/powerpc/include/asm/kvm_host.h |1 +
arch/powerpc/kvm/book3s_hv.c|4 ++--
arch/powerpc
Avi Kivity a...@redhat.com writes:
On 09/03/2012 03:33 PM, Rusty Russell wrote:
Avi Kivity a...@redhat.com writes:
On 09/01/2012 03:35 PM, Rusty Russell wrote:
Passing an address in a struct is pretty bad, since it involves
compatibility wrappers.
Right, some s390 thing.
Err, no, i386
Peter Maydell peter.mayd...@linaro.org writes:
On 1 September 2012 13:28, Rusty Russell ru...@rustcorp.com.au wrote:
Rusty Russell (8):
KVM: ARM: Fix walk_msrs()
KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code.
KVM: Add KVM_REG_SIZE() helper.
KVM: ARM: use
Christoffer Dall c.d...@virtualopensystems.com writes:
that's fine, but then the #define's shouldn't be called something with
COPROC in their names.
Sure, feel free to rename it. I failed to come up with a concise, clear
name, so coproc stuck.
Cheers,
Rusty.
--
To unsubscribe from this list:
Peter Maydell peter.mayd...@linaro.org writes:
On 5 September 2012 07:48, Rusty Russell ru...@rustcorp.com.au wrote:
Peter Maydell peter.mayd...@linaro.org writes:
I could live with always read/write 64 bits. I definitely don't
want to have to deal with matching up register widths to accesses
the BUG_ON()s above the indirect test, where they belong
(indirect falls thru on OOM, so the constraints still apply).
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/virtio/virtio_ring.c | 61 ---
1 file changed, 52 insertions(+), 9 deletions
the affinity hint
- if the virtqueues share MSI, make the affinity OR over all affinities
requested
Signed-off-by: Jason Wang jasow...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Applied, thanks.
Acked-by: Rusty Russell ru...@rustcorp.com.au
Cheers,
Rusty.
--
To unsubscribe from
Sasha Levin levinsasha...@gmail.com writes:
On Wed, Aug 29, 2012 at 05:03:03PM +0200, Sasha Levin wrote:
I've also re-ran it on a IBM server type host instead of my laptop. Here
are the
results:
Vanilla kernel:
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
.
But I've applied as-is, we can clean up that later if we want (probably
by merging the two structures, I'll have to think harder on that).
Acked-by: Rusty Russell ru...@rustcorp.com.au
Cheers,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
Michael S. Tsirkin m...@redhat.com writes:
virtio network device multiqueue support reserves
vq 3 for future use (useful both for future extensions and to make it
pretty - this way receive vqs have even and transmit - odd numbers).
Make it possible to skip initialization for
specific vq
Cornelia Huck cornelia.h...@de.ibm.com writes:
Add specifications for the new s390 specific virtio-ccw transport.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
Excellent. I have applied and pushed this revision.
I was tempted to ask for an explicit endian marker, as switching to
Paolo Bonzini pbonz...@redhat.com writes:
Il 02/07/2012 02:29, Rusty Russell ha scritto:
VIRTIO_BALLOON_F_MUST_TELL_HOST
implies you should tell the host (eventually). I don't know if any
implementations actually care though.
This is indeed broken, because it is a negative feature: it tells
Michael S. Tsirkin m...@redhat.com writes:
Yes without checksum net core always linearizes packets, so yes it is
screwed.
For -net, skb always allocates space for 17 frags + linear part so
it seems sane to do same in virtio core, and allocate, for -net,
up to max_frags + 1 from cache.
We can
Cornelia Huck cornelia.h...@de.ibm.com writes:
On Thu, 06 Sep 2012 11:56:31 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
Cornelia Huck cornelia.h...@de.ibm.com writes:
Add specifications for the new s390 specific virtio-ccw transport.
Signed-off-by: Cornelia Huck cornelia.h
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Sep 06, 2012 at 05:27:23PM +0930, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
Yes without checksum net core always linearizes packets, so yes it is
screwed.
For -net, skb always allocates space for 17 frags + linear
Avi Kivity a...@redhat.com writes:
On 09/06/2012 06:23 PM, Peter Maydell wrote:
On 6 September 2012 16:16, Avi Kivity a...@redhat.com wrote:
(and the APIC, if treated as one-large-register) is 4k)
...so don't do that then. Trying to treat the whole APIC
as a single register means you don't
Paolo Bonzini pbonz...@redhat.com writes:
Instead, VIRTIO_NET_F_HOST_MUST_SEND_GARP would be a negative feature:
if set, the host _may not_ rely on the guest to send a gARP. Similarly
if VIRTIO_BALLOON_F_MUST_TELL_HOST is set, the guest _may not_ use
ballooned pages directly.
There are _no_
Michael S. Tsirkin m...@redhat.com writes:
On Fri, Sep 07, 2012 at 09:15:46AM +0930, Rusty Russell wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Instead, VIRTIO_NET_F_HOST_MUST_SEND_GARP would be a negative feature:
if set, the host _may not_ rely on the guest to send a gARP. Similarly
Michael S. Tsirkin m...@redhat.com writes:
On Fri, Sep 07, 2012 at 04:09:50PM +0930, Rusty Russell wrote:
So it looks like a bug: we should teach driver to tell host first on leak?
Yan, Vadim, can you comment please?
Also if true, looks like this bit will be useful to detect a fixed
OK, I read the spec (pasted below for easy of reading), but I'm still
confused over how this will work.
I thought normal net drivers have the hardware provide an rxhash for
each packet, and we map that to CPU to queue the packet on[1]. We hope
that the receiving process migrates to that CPU, so
Michael S. Tsirkin m...@redhat.com writes:
On Sat, Sep 08, 2012 at 02:36:00PM +0930, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Fri, Sep 07, 2012 at 04:09:50PM +0930, Rusty Russell wrote:
So it looks like a bug: we should teach driver to tell host first on
leak
Michael S. Tsirkin m...@redhat.com writes:
In other words RPS is a hack to speed up networking on cheapo
hardware, this is one of the reasons it is off by default.
Good hardware has multiple receive queues.
We can implement a good one so we do not need RPS.
Also not all guest OS-es support
Michael S. Tsirkin m...@redhat.com writes:
We have several options:
1. No memory overcommit feature. This is always the case ATM!
2. Do not hot-plug assigned device.
3. Hot-unplug assigned device.
4. Some assigned devices can be able to handle memory errors
e.g. using ATS. Limit hotplug
Thomas Lendacky t...@linux.vnet.ibm.com writes:
I ran some TCP_RR and TCP_STREAM sessions, both host-to-guest and
guest-to-host, with a form of the histogram patch applied against a
RHEL6.3 kernel. The histogram values were reset after each test.
Hey, thanks! This is exactly what I wanted to
Mike Waychison mi...@google.com writes:
On Mon, Sep 10, 2012 at 3:59 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 10, 2012 at 01:37:06PM -0400, Mike Waychison wrote:
On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Jun 26, 2012 at 01:32:58PM
Jason Wang jasow...@redhat.com writes:
On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
A final addition: what you suggest above would be
TX follows RX, right?
BTW, yes. But it's a weird way to express what the nic is doing.
It is in anticipation of something like that, that I made
Tom Herbert therb...@google.com writes:
On Tue, Sep 11, 2012 at 10:49 PM, Rusty Russell ru...@rustcorp.com.auwrote:
Perhaps Tom can explain how we avoid out-of-order receive for the
accelerated RFS case? It's not clear to me, but we need to be able to
do that for virtio-net if it implements
Will Deacon will.dea...@arm.com writes:
On Sat, Sep 15, 2012 at 04:35:02PM +0100, Christoffer Dall wrote:
From: Rusty Russell rusty.russ...@linaro.org
We want some of these for use in KVM, so pull them out of
arch/arm/kernel/perf_event_v7.c into their own asm/perf_bits.h.
Signed-off
Asias He as...@redhat.com writes:
On 09/25/2012 10:36 AM, Asias He wrote:
This reduces unnecessary interrupts that host could send to guest while
guest is in the progress of irq handling.
If one vcpu is handling the irq, while another interrupt comes, in
handle_edge_irq(), the guest will
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
Asias He as...@redhat.com writes:
I forgot about the cool hack which MST put in to defer event updates
using disable_cb/enable_cb.
Hmm, are you talking about virtqueue_enable_cb_delayed()?
Just the fact that virtqueue_disable_cb() prevents updates of
used_index, and then we do the update in
Hi Stephen,
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/pub/scm/linux/kernel/git/rusty/linux.git
Branches:
modules-next
virtio-next
For others: beware that these will
Virtio devices are not supposed to depend on the framing of the scatter-gather
lists, but various implementations did. Safeguard this in future by adding
an option to deliberately create perverse descriptors.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/drivers/virtio/Kconfig
Rusty Russell ru...@rustcorp.com.au writes:
Michael S. Tsirkin m...@redhat.com writes:
Thinking about Sasha's patches, we can reduce ring usage
for virtio net small packets dramatically if we put
virtio net header inline with the data.
This can be done for free in case guest net stack
Michael S. Tsirkin m...@redhat.com writes:
Capacity math on ring full is wrong: we are
looking at num_sg but that might be optimistic
because of indirect buffer use.
The implementation also penalizes fast path
with extra memory accesses for the benefit of
ring full condition handling which
Paolo Bonzini pbonz...@redhat.com writes:
Il 03/10/2012 08:44, 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
Anthony Liguori anth...@codemonkey.ws writes:
Rusty Russell ru...@rustcorp.com.au writes:
Michael S. Tsirkin m...@redhat.com writes:
Thinking about Sasha's patches, we can reduce ring usage
for virtio net small packets dramatically if we put
virtio net header inline with the data.
This can
Anthony Liguori anth...@codemonkey.ws writes:
Rusty Russell ru...@rustcorp.com.au writes:
Michael S. Tsirkin m...@redhat.com writes:
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 my lack of attention :(
Here's the spec change:
commit 7e74459bb966ccbaad9e4bf361d1178b7f400b79
Author: Rusty Russell ru...@rustcorp.com.au
Date: Thu Oct 4 17:11:27 2012 +0930
No longer assume framing is independent of messages. *sniff*
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Paolo Bonzini pbonz...@redhat.com 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
):
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
Paolo Bonzini pbonz...@redhat.com writes:
Il 04/10/2012 14:51, Rusty Russell ha scritto:
Paolo Bonzini pbonz...@redhat.com 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
Min-gyu Kim mingyu84@samsung.com writes:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Christoffer Dall
Sent: Monday, October 01, 2012 4:22 AM
To: Will Deacon
Cc: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
(Topic updated, cc's trimmed).
Anthony Liguori aligu...@us.ibm.com writes:
Rusty Russell ru...@rustcorp.com.au writes:
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
Anthony Liguori aligu...@us.ibm.com writes:
Gerd Hoffmann kra...@redhat.com writes:
Hi,
So we could have for virtio something like this:
Capabilities: [??] virtio-regs:
legacy: BAR=0 offset=0
virtio-pci: BAR=1 offset=1000
Anthony Liguori aligu...@us.ibm.com writes:
We'll never remove legacy so we shouldn't plan on it. There are
literally hundreds of thousands of VMs out there with the current virtio
drivers installed in them. We'll be supporting them for a very, very
long time :-)
You will be supporting this
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 and never, so I'd really
rather not have to grandfather that in.
It is, but we can add
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 prefer being strict so
we catch bad
Gerd Hoffmann kra...@redhat.com writes:
So how about this:
(1) Add a vendor specific pci capability for new-style virtio.
Specifies the pci bar used for new-style virtio registers.
Guests can use it to figure whenever new-style virtio is
supported and to map the correct bar
Cornelia Huck cornelia.h...@de.ibm.com writes:
On Thu, 27 Sep 2012 09:59:33 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
3) Various clarifications, formalizations and cleanups to the spec text,
and possibly elimination of old deprecated features.
4) The only significant change
Anthony Liguori aligu...@us.ibm.com writes:
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori aligu...@us.ibm.com writes:
We'll never remove legacy so we shouldn't plan on it. There are
literally hundreds of thousands of VMs out there with the current virtio
drivers installed
On Thu, 9 Jul 2009 03:42:20 am Christoph Hellwig wrote:
On Tue, Jun 23, 2009 at 04:43:10PM +0930, Rusty Russell wrote:
On Sun, 21 Jun 2009 04:59:41 am Christoph Hellwig wrote:
Block driver ioctl methods must return ENOTTY and not -ENOIOCTLCMD if
they expect the block layer to handle
On Wed, 22 Jul 2009 01:29:09 am Michael S. Tsirkin wrote:
Free up msi vector tables.
Michael, this papers over the bug, but doesn't actually fix the problem.
The problem is that vp_free_vectors() does not do the reverse of
vp_request_vectors. If the author (you) can't get it right, what hope
On Wed, 22 Jul 2009 01:29:25 am Michael S. Tsirkin wrote:
- if (info-vector != VIRTIO_MSI_NO_VECTOR)
+ if (info-vector != VIRTIO_MSI_NO_VECTOR) {
free_irq(vp_dev-msix_entries[info-vector].vector, vq);
+ --vp_dev-msix_used_vectors;
+ }
This only works
On Thu, 23 Jul 2009 09:27:31 pm Michael S. Tsirkin wrote:
msix_user_vectors counted both per-vq and shared/config vectors.
This causes BUG_ON when device is removed, as
free_vectors tries to free per-vq vectors.
OK, I looked at this patch, then looked at this code (after it was applied).
I'm
On Thu, 23 Jul 2009 09:27:37 pm Michael S. Tsirkin wrote:
Make vp_free_vectors do the reverse of vq_request_vectors.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Thanks, applied!
Rusty.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
to setup_vq.
4) Fix spaces to tabs
5) Make nvectors calc internal to vp_try_to_find_vqs()
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/virtio/virtio_pci.c | 84 +++-
1 file changed, 45 insertions(+), 39 deletions(-)
diff --git a/drivers
On Tue, 28 Jul 2009 03:34:33 am Amit Shah wrote:
We expose multiple char devices (ports) for simple communication
between the host userspace and guest.
Hi Amit,
OK, seems like it's time for some serious review. Below.
+config VIRTIO_SERIAL
+ tristate Virtio serial
+ select
On Tue, 28 Jul 2009 06:03:08 pm Michael S. Tsirkin wrote:
On Tue, Jul 28, 2009 at 12:44:31PM +0930, Rusty Russell wrote:
On Mon, 27 Jul 2009 01:17:09 am Michael S. Tsirkin wrote:
This refactors find_vqs, making it more readable and robust, and fixing
two regressions from 2.6.30
On Mon, 10 Aug 2009 07:17:54 pm Gerd Hoffmann wrote:
On 08/10/09 08:55, Amit Shah wrote:
Bad example. Quite a lot of modern devices drivers are using dynamic
major/minor numbers because they have proven to be such a pain in the
butt. That's why we have more sophisticated mechanisms like
On Tue, 11 Aug 2009 04:22:53 pm Avi Kivity wrote:
On 08/11/2009 09:32 AM, Pierre Ossman wrote:
On Mon, 13 Jul 2009 23:59:52 +0900
Minchan Kimminchan@gmail.com wrote:
Any ideas here? Is the virtio net driver very GFP_ATOMIC happy so it
drains all those pages? And why is this triggered
On Wed, 12 Aug 2009 12:49:51 pm Rusty Russell wrote:
On Tue, 11 Aug 2009 04:22:53 pm Avi Kivity wrote:
On 08/11/2009 09:32 AM, Pierre Ossman wrote:
I doesn't get out of it though, or at least the virtio net driver
wedges itself.
There's a fixme to retry when this happens
On Wed, 12 Aug 2009 03:11:21 pm Avi Kivity wrote:
+ /* In theory, this can happen: if we don't get any buffers in
+* we will*never* try to fill again. Sleeping in keventd if
+* bad, but that is worse. */
+ if (still_empty) {
+ msleep(100);
+
On Tue, 11 Aug 2009 09:22:58 pm Avi Kivity wrote:
(copying Rusty, the virtio maintainer)
On 08/10/2009 11:05 PM, Shirley Ma wrote:
Whild reading virtio code, I found some memory leak in removing
virtio_net.
In virtnet_remove, only skb has been freed not the pages in skb
frags. Here
On Thu, 13 Aug 2009 03:05:48 am Michael S. Tsirkin wrote:
On Mon, Aug 10, 2009 at 03:51:12PM -0500, Anthony Liguori wrote:
Any rough idea on performance? Better or worse than userspace?
Well, I definitely see some gain in latency.
...
Part of it might be that tx mitigation does not come
On Fri, 14 Aug 2009 12:23:46 am Arnd Bergmann wrote:
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
The best way to do this IMO would be to add zero copy support to raw
sockets, vhost will then get it basically for free.
Yes, that would be nice. I wonder if that could lead to
On Thu, 20 Aug 2009 12:30:29 am Michael S. Tsirkin wrote:
Rusty, could you review and comment on the patches please? Since most
of the code deals with virtio from host side, I think it will make sense
to merge them through your tree. What do you think?
Yep, I've been waiting for all the other
On Thu, 20 Aug 2009 12:33:09 am Michael S. Tsirkin wrote:
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest without modification.
...
+config VHOST_NET
+ tristate
On Thu, 20 Aug 2009 05:14:29 pm Gerd Hoffmann wrote:
I think strings are better as numbers for identifying protocols as you
can work without a central registry for the numbers then.
Yep, all you need is a central registry for names :)
Rusty.
--
To unsubscribe from this list: send the line
On Fri, 21 Aug 2009 06:26:16 am Christoph Hellwig wrote:
Currently virtio-blk doesn't set any QUEUE_ORDERED_ flag by default, which
means it does not allow filesystems to use barriers. But the typical use
case for virtio-blk is to use a backed that uses synchronous I/O
Really? Does qemu open
On Fri, 14 Aug 2009 05:55:48 am Pierre Ossman wrote:
On Wed, 12 Aug 2009 15:01:52 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
Subject: virtio: net refill on out-of-memory
...
Patch applied. Now we wait. :)
Any results?
Thanks,
Rusty.
--
To unsubscribe from this list: send the line
On Tue, 25 Aug 2009 10:04:41 pm Arnd Bergmann wrote:
On Tuesday 25 August 2009, Avi Kivity wrote:
On 08/25/2009 05:22 AM, Anthony Liguori wrote:
I think 2.6.32 is pushing it.
2.6.32 is pushing it, but we need to push it.
Agreed.
Get real. It's not happening.
We need migration
On Tue, 25 Aug 2009 11:46:08 pm Christoph Hellwig wrote:
On Tue, Aug 25, 2009 at 11:41:37PM +0930, Rusty Russell wrote:
On Fri, 21 Aug 2009 06:26:16 am Christoph Hellwig wrote:
Currently virtio-blk doesn't set any QUEUE_ORDERED_ flag by default, which
means it does not allow filesystems
On Wed, 26 Aug 2009 02:25:01 pm Pierre Ossman wrote:
On Wed, 26 Aug 2009 11:47:17 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
On Fri, 14 Aug 2009 05:55:48 am Pierre Ossman wrote:
On Wed, 12 Aug 2009 15:01:52 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
Subject: virtio: net
On Tue, 25 Aug 2009 09:34:34 pm Michael S. Tsirkin wrote:
That's because we didn't do the request_irq's for the per_vector case,
because
we don't have the names. This is what prevented me from doing a nice
encapsulation.
Yes. But let's split free_vectors out into free_msix_vectors and
On Thu, 27 Aug 2009 02:26:55 am Michael S. Tsirkin wrote:
On Tue, Aug 25, 2009 at 04:16:34PM +0300, Michael S. Tsirkin wrote:
+ /* If they don't want an interrupt, don't send one, unless
empty. */
+ if ((flags VRING_AVAIL_F_NO_INTERRUPT) vq-inflight)
+
On Wed, 26 Aug 2009 09:58:13 pm Avi Kivity wrote:
On 08/26/2009 03:06 PM, Rusty Russell wrote:
On Tue, 25 Aug 2009 11:46:08 pm Christoph Hellwig wrote:
On Tue, Aug 25, 2009 at 11:41:37PM +0930, Rusty Russell wrote:
On Fri, 21 Aug 2009 06:26:16 am Christoph Hellwig wrote
On Wed, 26 Aug 2009 03:41:20 am Christoph Hellwig wrote:
As various people wanted to know how the various data integrity patches
I've send out recently play together here's a small writeup on what
issues we have in QEMU and how to fix it:
Classic mail. Thanks for the massive and coherent clue
On Thu, 27 Aug 2009 07:19:26 pm Michael S. Tsirkin wrote:
On Thu, Aug 27, 2009 at 07:00:34PM +0930, Rusty Russell wrote:
On Tue, 25 Aug 2009 09:34:34 pm Michael S. Tsirkin wrote:
That's because we didn't do the request_irq's for the per_vector case,
because
we don't have the names
On Thu, 27 Aug 2009 07:40:26 pm Michael S. Tsirkin wrote:
On Wed, Aug 26, 2009 at 03:40:59PM +0200, Arnd Bergmann wrote:
On Tuesday 25 August 2009, Michael S. Tsirkin wrote:
I'd like to avoid that here,
though it's kind of ugly. We'd need VHOST_GET_FEATURES (and ACK) to
take a
On Thu, 27 Aug 2009 08:15:18 pm Michael S. Tsirkin wrote:
On Tue, Aug 25, 2009 at 09:40:40PM +0930, Rusty Russell wrote:
Also, see other fixes to the lguest launcher since then which might
be relevant to this code:
lguest: get more serious about wmb() in example Launcher code
Heh
On Thu, 27 Aug 2009 08:34:19 pm Avi Kivity wrote:
There are two possible semantics to cache=writeback:
- simulate a drive with a huge write cache; use fsync() to implement
barriers
- tell the host that we aren't interested in data integrity, lie to the
guest to get best performance
Why
201 - 300 of 640 matches
Mail list logo
