On Wed, 20 May 2009 05:03:01 pm Christian Bornträger wrote:
> Am Mittwoch 20 Mai 2009 04:58:38 schrieb Rusty Russell:
> > But what's it *for*, this shared memory?
...
> z/VM uses these segments for several purposes:
> o The monitoring subsystem uses a DCSS to get data from se
On Tue, 26 May 2009 11:16:08 pm Christian Borntraeger wrote:
> Hello Rusty,
>
> here are two patches that change the device matching of the virtio bus.
> The patches have been refreshed agains linux-next and should apply
> to your private virtio tree.
>
> OK for linux-next?
Sure, added.
Thanks!
R
On Wed, 27 May 2009 05:19:19 pm Christoph Hellwig wrote:
> You should probably include rusty as he's collecting the patches
> for the virtio guest drivers.
Yes. It *does* help to cc the maintainer if you want your patches applied :)
And I particularly love untested code like this!
> + if (!
On Fri, 29 May 2009 01:45:27 pm john cooper wrote:
> virtio_blk-serial-4.patch
Hate to ask dumb questions, but is there a scsi equivalent of this? It'd be
nice if we could avoid being ATA-specific in the long run...
Also, why u16?
Thanks,
Rusty.
> +/* return ATA identify data
> + */
> +static
e eventfds for device notification
Currently, when a Guest wants to perform I/O it calls LHCALL_NOTIFY with
an address: the main Launcher process returns with this address, and figures
out what device to run.
A far nicer model is to let processes bind an eventfd to an address: if we
find one, we s
On Fri, 5 Jun 2009 09:26:48 pm Gregory Haskins wrote:
> Hi Rusty,
>
> Rusty Russell wrote:
> > On Fri, 5 Jun 2009 04:19:17 am Gregory Haskins wrote:
> >> Avi Kivity wrote:
> >>> Gregory Haskins wrote:
> >>> One idea is similar to signalfd() or event
On Fri, 5 Jun 2009 03:00:10 pm Paul E. McKenney wrote:
> On Fri, Jun 05, 2009 at 02:25:01PM +0930, Rusty Russell wrote:
> > + /* lg->eventfds is RCU-protected */
> > + preempt_disable();
>
> Suggest changing to rcu_read_lock() to match the synchronize_rcu().
Ah yes
. The structure
data is copied wholesale to userspace via a
HDIO_GET_IDENTITY ioctl command (eg: hdparm -i ).
Signed-off-by: john cooper
Signed-off-by: Rusty Russell
---
drivers/block/virtio_blk.c | 37 ++---
include/linux/virtio_blk.h |4
2 files changed
On Thu, 4 Jun 2009 06:37:19 am you wrote:
> This patch extracts the opaque data from pci i/o
> region 0 via the added VIRTIO_BLK_F_IDENTIFY
> field.
Thanks John, I fixed textual conflicts and forwarded it to Jens: he has the
other pending virtio_blk patches as well.
I removed one comment:
> +/*
On Fri, 5 Jun 2009 02:13:20 am Michael S. Tsirkin wrote:
> I out up a copy at http://www.linux-kvm.org/page/Networking_Performance as
> well, and intend to dump updates there from time to time.
Hi Michael,
Sorry for the delay. I'm weaning myself off my virtio work, but virtio_net
performance
On Mon, 8 Jun 2009 02:46:08 pm Herbert Xu wrote:
> On Fri, Jun 05, 2009 at 05:16:31PM -0700, Sridhar Samudrala wrote:
> > + /* Software UFO is not yet supported */
> > + segs = ERR_PTR(-EPROTONOSUPPORT);
>
> Hmm, we need to fill this in before you start using it for virt.
> After all, it's very
On Wed, 10 Jun 2009 03:56:31 pm Dor Laor wrote:
> Rusty Russell wrote:
> > The current theoretical hole is that the host suppresses notifications
> > using the VIRTIO_AVAIL_F_NO_NOTIFY flag, but we can get a number of
> > notifications in before it gets to that suppre
On Mon, 15 Jun 2009 10:24:39 pm Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 08:08:18AM -0400, Gregory Haskins wrote:
> > Hmm. I understand what you are saying conceptually (i.e. the .text
> > could get yanked before we hit the next line of code, in this case the
> > "return 0"). However,
On Mon, 22 Jun 2009 09:24:20 am Davide Libenzi wrote:
> I actually ended up exposing the eventfd context anyway, since IMO is a
> better option instead of holding references to the eventfd file (that
> makes VFS people uneasy).
lguest is a special case since we don't let them close the fds, except
On Sun, 21 Jun 2009 04:02:15 am Christoph Hellwig wrote:
> Looks like I sent a patch that doesn't actually compile because qui
> decided to apply those fixes to a different one. Here's the correc
> one:
>
> --
>
> Subject: virtio_blk: don't bounce highmem requests
> From: Christoph Hellwig
>
> By
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 generic ioctls.
>
> This triggered a BLKROSET failure in xfsqa #200.
Applied.
Thanks,
Rusty.
--
To unsubscribe from this list: s
On Tue, 23 Jun 2009 03:33:22 am Davide Libenzi wrote:
> What you're doing there, is setting up a kernel-to-kernel (since
> userspace only role is to create the eventfd) communication, using a file*
> as accessory. That IMO is plain wrong.
The most sensible is that userspace can use these fds; an i
On Fri, 19 Jun 2009 04:57:34 pm Christian Bornträger wrote:
> Hello Rusty,
>
> this is a result of a two month internship about virtio testing.
Interesting!
> I would like to get feedback on
>
> o the general idea of a virtio_test module
> o the user interface ioctls
> o further ideas and comm
On Tue, 23 Jun 2009 10:12:31 pm Amit Shah wrote:
> Hello,
>
> Here are two patches. One implements a virtio-serial device in qemu
> and the other is the driver for a guest kernel.
>
> While working on a vmchannel interface that is needed for communication
> between guest userspace and host userspac
On Wed, 24 Jun 2009 10:09:37 pm Amit Shah wrote:
> On (Wed) Jun 24 2009 [13:45:01], Rusty Russell wrote:
> > On Tue, 23 Jun 2009 10:12:31 pm Amit Shah wrote:
> > > Hello,
> > >
> > > Here are two patches. One implements a virtio-serial device in qemu
> >
On Thu, 25 Jun 2009 08:15:11 am Davide Libenzi wrote:
> On Wed, 24 Jun 2009, Rusty Russell wrote:
> > On Tue, 23 Jun 2009 03:33:22 am Davide Libenzi wrote:
> > > What you're doing there, is setting up a kernel-to-kernel (since
> > > userspace only role is to c
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
> > > the
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 onl
On Sun, 3 Jul 2011 15:11:37 +0300, "Michael S. Tsirkin" 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
>
> (a
On Sat, 13 Aug 2011 11:51:01 +0300, Sasha Levin 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 general, we have to do vir
On Sun, 14 Aug 2011 16:57:32 +0300, Sasha Levin wrote:
> On Sun, 2011-08-14 at 12:23 +0930, Rusty Russell wrote:
> > On Sat, 13 Aug 2011 11:51:01 +0300, Sasha Levin
> > wrote:
> > > The MAC of a virtio-net device is located at the first field of the device
> > >
>
> > This patch moves the MAC probe to after the detection 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
> > Cc: Michael S. Tsirkin
> > Cc: virtualiza
On Mon, 22 Aug 2011 11:36:13 +0300, "Michael S. Tsirkin"
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 the device, t
On Wed, 4 Jul 2012 13:55:33 +0300, "Michael S. Tsirkin" wrote:
> On Tue, Jul 03, 2012 at 10:17:46AM +0930, Rusty Russell wrote:
> > On Mon, 2 Jul 2012 13:08:19 -0300, Rafael Aquini wrote:
> > > As 'locking in balloon', may I assume the approach I took for
On Thu, 5 Jul 2012 12:08:22 +0200, Paolo Bonzini wrote:
> The old name is part of the userspace API, add it back for compatibility.
>
> Reported-by: Sasha Levin
> Signed-off-by: Paolo Bonzini
> ---
> include/linux/virtio_blk.h |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
On Thu, 5 Jul 2012 15:22:25 +0300, "Michael S. Tsirkin" wrote:
> On Thu, Jul 05, 2012 at 12:07:07PM +0200, Paolo Bonzini wrote:
> > The KVM list is followed by more people than the generic
> > virtualizat...@lists.linux-foundation.org mailing list, and is
> > already "de facto" the place where vir
On Wed, 4 Jul 2012 16:02:36 +0200, Paolo Bonzini wrote:
> This completes the changes from yesterday.
>
> Signed-off-by: Paolo Bonzini
Thanks, applied!
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More ma
On Thu, 05 Jul 2012 09:02:23 +0200, Sasha Levin wrote:
> On Thu, 2012-07-05 at 08:47 +0200, Paolo Bonzini wrote:
> > Il 04/07/2012 23:11, Sasha Levin ha scritto:
> > > There are two things going on here:
> > > 1. Rename VIRTIO_BLK_F_FLUSH to VIRTIO_BLK_F_WCE
> > > 2. Add a new VIRTIO_BLK_F_CONFI
On Fri, 13 Jul 2012 01:59:41 +0300, "Michael S. Tsirkin"
wrote:
> It looks like there's a problem in the way virtio config currently
> works: if driver reads config in probe routine, config
> subsequently can change before core sets DRIVER_OK.
> This will not cause an interrupt and so this event
On Mon, 16 Jul 2012 16:24:37 +0200, Paolo Bonzini wrote:
> This adds an event for changes to LUN parameters, for example capacity. These
> are reported in virtio-blk via configuration changes, and we want a similar
> functionality in virtio-scsi too.
Both applied.
Thanks!
Rusty.
--
To unsubscri
On Mon, 23 Jul 2012 22:32:39 +0200, Sasha Levin wrote:
> As it was discussed recently, there's currently no way for the guest to notify
> the host about panics. Further more, there's no reasonable way to notify the
> host of other critical events such as an OOM kill.
I clearly missed the discussi
On Tue, 24 Jul 2012 15:01:59 +0200, Sasha Levin wrote:
> virtio on it's own was introduced to help solve the fragmentation
> around virtualized devices, so I don't think that the main purpose of
> doing virtio drivers is due to any performance benefits virtio may
> provide.
There's one argument i
; nlkt, lguest, and probably others.
>
> linux/virtio_blk.h is a public kernel header, which is supposed to be
> used from userspace - so I assume many others who implemented virtio-blk
> for any reason took advantage of that header.
BTW, I have patched this myself now:
From: Rusty Russe
On Fri, 13 Jul 2012 16:38:51 +0800, Asias He wrote:
> Add 'virtio_blk.use_bio=1' to kernel cmdline or 'modprobe virtio_blk
> use_bio=1' to enable ->make_request_fn() based I/O path.
This patch conflicts with Paolo's Bonzini's 'virtio-blk: allow toggling
host cache between writeback and writethrou
On Fri, 13 Jul 2012 16:38:51 +0800, Asias He wrote:
> This patch introduces bio-based IO path for virtio-blk.
Acked-by: Rusty Russell
I just hope we can do better than a module option in future.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
terlist stuff is complete crack, but I lost that
debate years ago.)
Here's my variant. Networking, console and block seem OK, at least
(ie. it booted!).
From: Rusty Russell
Subject: virtio: use chained scatterlists.
Rather than handing a scatterlist[] and out and in numbers to
virtqueue_
On Fri, 27 Jul 2012 10:11:26 +0200, Paolo Bonzini wrote:
> Il 27/07/2012 08:27, Rusty Russell ha scritto:
> >> > +int virtqueue_add_buf_sg(struct virtqueue *_vq,
> >> > + struct scatterlist *sg_out,
> >> > +
On Sun, 29 Jul 2012 14:11:15 +0300, "Michael S. Tsirkin"
wrote:
> On Sat, Jul 28, 2012 at 10:21:05AM +0800, Asias He wrote:
> > This patch introduces bio-based IO path for virtio-blk.
> >
> > Compared to request-based IO path, bio-based IO path uses driver
> > provided ->make_request_fn() method
cache between writeback and writethrough
Rusty Russell (1):
virtio-blk: return VIRTIO_BLK_F_FLUSH to header.
drivers/block/virtio_blk.c | 115 ---
drivers/char/hw_random/virtio-rng.c | 37 ++-
include/linux/virtio_blk.h |
On Tue, 7 Aug 2012 16:52:47 +0200, Cornelia Huck
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 virtio_mmio (drivers/virtio/vi
On Mon, 13 Aug 2012 10:56:38 +0200, Cornelia Huck
wrote:
> On Wed, 08 Aug 2012 13:52:57 +0930
> Rusty Russell wrote:
>
> > On Tue, 7 Aug 2012 16:52:47 +0200, Cornelia Huck
> > wrote:
> > 1) Please don't limit yourself to 32 feature bits! If you look at how
On Tue, 14 Aug 2012 13:03:34 +0200, Cornelia Huck
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 parts here, of
On Tue, 14 Aug 2012 14:56:07 -0500, Anthony Liguori wrote:
> Cornelia Huck 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 commands in order
> > to perform
On Wed, 15 Aug 2012 09:48:44 +0200, Christian Borntraeger
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. Text wil
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
*ev
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
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
+++ b/arch/arm/in
This trivially replaces the arm-specific KVM_VCPU_GET_MSR_INDEX_LIST.
Signed-off-by: Rusty Russell
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 kvm_s390_ucas_mapping {
#define
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
ses 64-bit indices.
Signed-off-by: Rusty Russell
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
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index a29e091..7506652 100644
--- a/arch/powerpc
Peter Maydell writes:
> On 29 August 2012 00:48, Rusty Russell 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 of
Rusty Russell 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 into
>
Peter Maydell writes:
> On 29 August 2012 00:37, Rusty Russell 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 is the conve
Rusty Russell 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 t
Avi Kivity 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 o
Rusty Russell writes:
> Rusty Russell 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
Avi Kivity 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 p
On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin"
wrote:
> On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > Maybe this is better solved by copying the way it was done in PCI itself
> > with capability linked list?
>
> There are any number of ways to lay out the structure.
On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin"
wrote:
> On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin"
> > wrote:
> > > On Fri, Aug 19, 2011 at 07:33:07PM +03
On Thu, 22 Sep 2011 20:59:13 +0200, Christian Borntraeger
wrote:
> On 22/09/11 20:14, Amit Shah wrote:
> > Hi Rusty,
> >
> > This is a fix from Christian for early console handling with multiport
> > support. Please apply.
> >
> > Christian, I've made some changes to the patch as noted in the
On Sun, 2 Oct 2011 11:09:00 +0200, "Michael S. Tsirkin" wrote:
> On Mon, Sep 19, 2011 at 05:19:49PM +0930, Rusty Russell wrote:
> > On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin"
> > wrote:
> > > On Mon, Sep 19, 2011 at 01:05:17PM +0930,
On Wed, 05 Oct 2011 15:54:08 -0400, Christoph Hellwig
wrote:
> Add an alternate I/O path that implements ->make_request for virtio-blk.
> This is required for high IOPs devices which get slowed down to 1/5th of
> the native speed by all the locking, memory allocation and other overhead
> in the r
On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang wrote:
> This make let virtio-net driver can send gratituous packet by a new
> config bit - VIRTIO_NET_S_ANNOUNCE in each config update
> interrupt. When this bit is set by backend, the driver would schedule
> a workqueue to send gratituous packet thr
On Mon, 24 Oct 2011 12:02:18 +0200, Jens Axboe wrote:
> On 2011-10-24 12:02, Michael S. Tsirkin wrote:
> > On Wed, Oct 19, 2011 at 12:12:20PM +0200, Michael S. Tsirkin wrote:
> > Rusty, any opinion on merging this for 3.2?
> > I expect merge window will open right after the summit,
>
> I can toss
On Wed, 26 Oct 2011 16:49:12 +0800, Jason Wang wrote:
> Network connections in guest need to be kept after migration. This is done by
> sending gratuitous packet and let switch learn new port of the mac
> address. As hypervisor does not have the knowledge of guest network
> configurations such as
gt; > Changes from Mark's versions:
> > use the new ida_simple_get
> > error handling cleanup
> > fix user after free
> >
> > Works fine for me.
> >
> > Jens, could you merge this for 3.2?
> > That is, unless Rusty complains shortly ...
>
On Tue, 1 Nov 2011 14:42:23 +0200, "Michael S. Tsirkin" wrote:
> On Tue, Nov 01, 2011 at 02:33:33PM +0200, Sasha Levin wrote:
> > A proper solution would be for example a configuration in the PIO config
> > space which points to the MMIO BAR to use instead.
>
> I think it makes sense to put the c
On Tue, 1 Nov 2011 16:40:45 +0200, "Michael S. Tsirkin" wrote:
> On Thu, Oct 06, 2011 at 11:18:28AM -0200, Michael S. Tsirkin wrote:
> > On Thu, Oct 06, 2011 at 12:15:36PM +1030, Rusty Russell wrote:
> > > On Wed, 05 Oct 2011 15:54:05 -0400, Christoph Hellwig
On Wed, 02 Nov 2011 06:52:44 +0200, Sasha Levin wrote:
> Since the PCI spec allows you to have the MSI-X table and the PBA in
> completely different regions pointed by two different BARs, we did so in
> kvm tools and have BAR 1 pointing to the MSI-X table, and BAR 2 pointing
> to the PBA ( - we *a
On Wed, 02 Nov 2011 20:49:27 +0200, Sasha Levin wrote:
> This is a proposal for a new layout of the virtio-pci config space.
>
> We will separate the current configuration into two: A virtio-pci common
> configuration and a device specific configuration. This allows more
> flexibility
> with add
On Wed, 2 Nov 2011 03:25:44 -0400, Christoph Hellwig wrote:
> On Wed, Nov 02, 2011 at 01:49:36PM +1030, Rusty Russell wrote:
> > I thought it was still a WIP?
>
> The whole series - yes. This patch (and the serial number rewrite): no
> - these are pretty much rock solid.
OK,
On Thu, 03 Nov 2011 14:31:48 +1030, Rusty Russell wrote:
> So let's change the API for everyone, into:
>
> bool virtqueue_should_kick(struct virtqueue *vq);
> void virtqueue_kick(struct virtqueue *vq);
>
> Patch series coming...
Nope, that sucked. virt
ad to recreated it from memory.
Pointers to the original or corrections for the commit message
are welcome.
Signed-off-by: Rusty Russell
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -2
Since we know vq->vring.num is a power of 2, modulus is lazy (it's asserted
in vring_new_virtqueue()).
Signed-off-by: Rusty Russell
---
drivers/virtio/virtio_ring.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lgues
can't see the buffers until the kick.
Signed-off-by: Rusty Russell
---
drivers/virtio/virtio_ring.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
--- a/drivers/virtio/vir
The old documentation is left over from when we used a structure with
strategy pointers.
Signed-off-by: Rusty Russell
---
include/linux/virtio.h | 130 -
1 file changed, 87 insertions(+), 43 deletions(-)
diff --git a/include/linux/virtio.h b
Remove wrapper functions. This makes the allocation type explicit in
all callers; I used GPF_KERNEL where it seemed obvious, left it at
GFP_ATOMIC otherwise.
Signed-off-by: Rusty Russell
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
--- a/drivers/block/virtio_blk.c
+++ b
On Thu, 3 Nov 2011 09:51:15 +0200, Pekka Enberg wrote:
> On Thu, Nov 3, 2011 at 9:42 AM, Rusty Russell wrote:
> > Since we know vq->vring.num is a power of 2, modulus is lazy (it's asserted
> > in vring_new_virtqueue()).
> >
> > Signed-off-by: Rusty R
On Thu, 03 Nov 2011 10:33:23 +0200, Sasha Levin wrote:
> On Thu, 2011-11-03 at 12:28 +1030, Rusty Russell wrote:
> > 2) I don't think we want to turn the device-specific config into a
> >linked list. We haven't needed variable-length config (yet!), and
> >
On Thu, 3 Nov 2011 03:52:11 -0400, Christoph Hellwig wrote:
> On Thu, Nov 03, 2011 at 06:12:51PM +1030, Rusty Russell wrote:
> > Based on patch by Christoph for virtio_blk speedup:
>
> Please credit it to Stefan - he also sent a pointer to his original
> version in reply to t
On Sun, 06 Nov 2011 22:40:20 +0200, Sasha Levin wrote:
> The solution is also simple to explain: Split the devices into different
> processes and use seccomp to sandbox each device into the exact set of
> resources it needs to operate, nothing more and nothing less.
lguest does a process per devi
On Sun, 6 Nov 2011 23:38:49 +0200, "Michael S. Tsirkin" wrote:
> On Sun, Nov 06, 2011 at 10:24:57PM +0200, Sasha Levin wrote:
> > On Sun, 2011-11-06 at 09:30 +0200, Michael S. Tsirkin wrote:
> > > On Fri, Nov 04, 2011 at 04:53:05PM +0200, Sasha Levin wrote:
> > > > > I guess my assumption is that
On Mon, 07 Nov 2011 12:03:38 -0600, Anthony Liguori
wrote:
> So the sandbox loop would look like:
>
> void main() {
>setup_devices();
>
>read_from_event_channel(main_channel);
>for i in vrings:
> check_vring_notification(i);
> }
lguest uses a model where you attach an eventfd
On Mon, 07 Nov 2011 08:29:03 +0200, Sasha Levin wrote:
> On Mon, 2011-11-07 at 10:37 +1030, Rusty Russell wrote:
> > On Sun, 06 Nov 2011 22:40:20 +0200, Sasha Levin
> > wrote:
> > > The solution is also simple to explain: Split the devices into different
> >
On Mon, 07 Nov 2011 11:26:53 +0200, Avi Kivity wrote:
> One thing to beware of is memory hotplug. If the memory map is static,
> then a fork() once everything is set up (with MAP_SHARED) alllows all
> processes to access guest memory. However, if memory hotplug is
> supported (or planned to be s
On Mon, 7 Nov 2011 23:14:14 +0200, "Michael S. Tsirkin" wrote:
> On Mon, Nov 07, 2011 at 03:46:23PM +1030, Rusty Russell wrote:
> > So far, the only three things make sense to have in a capability list:
> > MSI-X, the upper 32 feature bits, and the per-device config.
>
On Tue, 8 Nov 2011 08:32:50 +0200, "Michael S. Tsirkin" wrote:
> On Tue, Nov 08, 2011 at 10:23:33AM +1030, Rusty Russell wrote:
> > Even so, should we just use the PCI cap list, and have each
> > cap entry just contain a BIR & offset?
> >
> > Thanks,
&
On Wed, 09 Nov 2011 22:57:28 +0200, Sasha Levin wrote:
> On Wed, 2011-11-09 at 22:52 +0200, Michael S. Tsirkin wrote:
> > On Wed, Nov 09, 2011 at 10:24:47PM +0200, Sasha Levin wrote:
> > > It'll be a bit harder deprecating it in the future.
> >
> > Harder than ... what ?
>
> Harder than allowing
On Sun, 13 Nov 2011 23:03:14 +0200, "Michael S. Tsirkin"
wrote:
> On Thu, Nov 03, 2011 at 06:12:53PM +1030, Rusty Russell wrote:
> > A virtio driver does virtqueue_add_buf() multiple times before finally
> > calling virtqueue_kick(); previously we only exposed the
On Mon, 14 Nov 2011 15:05:07 +0200, "Michael S. Tsirkin"
wrote:
> On Mon, Nov 14, 2011 at 02:25:17PM +0200, Pekka Enberg wrote:
> > On Mon, Nov 14, 2011 at 4:04 AM, Asias He wrote:
> > > Why both the bandwidth and latency performance are dropping so
> > > dramatically
> > > with multiple VQ?
>
On Mon, 14 Nov 2011 08:56:06 +0200, "Michael S. Tsirkin"
wrote:
> On Sun, Nov 13, 2011 at 11:03:13PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 03, 2011 at 06:12:53PM +1030, Rusty Russell wrote:
> > > A virtio driver does virtqueue_add_buf() multiple times
On Sun, 13 Nov 2011 17:14:27 +0200, "Michael S. Tsirkin"
wrote:
> On Fri, Nov 11, 2011 at 02:54:31PM +1030, Rusty Russell wrote:
> > Indeed, I'd like to see two changes to your proposal:
> >
> > (1) It should be all or nothing. If a driver can find the
On Fri, 11 Nov 2011 09:39:13 +0200, Sasha Levin wrote:
> On Fri, Nov 11, 2011 at 6:24 AM, Rusty Russell wrote:
> > (2) There's no huge win in keeping the same layout. Let's make some
> > cleanups. There are more users ahead of us then behind us (I
> > hope!
On Wed, 16 Nov 2011 09:23:17 +0200, "Michael S. Tsirkin"
wrote:
> On Wed, Nov 16, 2011 at 10:34:42AM +1030, Rusty Russell wrote:
> > On Mon, 14 Nov 2011 15:05:07 +0200, "Michael S. Tsirkin"
> > wrote:
> > > On Mon, Nov 14, 2011 at 02:25:17PM +0200
1 - 100 of 669 matches
Mail list logo
