* Re: [PATCH 005/206] Staging: hv: Rename the device type variable
From: Jonathan Cameron @ 2011-05-10 10:11 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, Haiyang Zhang,
Abhishek Kane
In-Reply-To: <1304978288-22999-5-git-send-email-kys@microsoft.com>
On 05/09/11 22:54, K. Y. Srinivasan wrote:
> Rename the variable g_blk_device_type.
Why?
A few of these renames could do with a bit more detail on what is wrong
with the old names.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
> Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
> ---
> drivers/staging/hv/blkvsc_drv.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/hv/blkvsc_drv.c b/drivers/staging/hv/blkvsc_drv.c
> index b54130b..51d1265 100644
> --- a/drivers/staging/hv/blkvsc_drv.c
> +++ b/drivers/staging/hv/blkvsc_drv.c
> @@ -115,7 +115,7 @@ struct block_device_context {
> static const char *drv_name = "blkvsc";
>
> /* {32412632-86cb-44a2-9b5c-50d1417354f5} */
> -static const struct hv_guid g_blk_device_type = {
> +static const struct hv_guid dev_type = {
> .data = {
> 0x32, 0x26, 0x41, 0x32, 0xcb, 0x86, 0xa2, 0x44,
> 0x9b, 0x5c, 0x50, 0xd1, 0x41, 0x73, 0x54, 0xf5
> @@ -178,7 +178,7 @@ static int blk_vsc_initialize(struct hv_driver *driver)
> /* Make sure we are at least 2 pages since 1 page is used for control */
>
> driver->name = drv_name;
> - memcpy(&driver->dev_type, &g_blk_device_type, sizeof(struct hv_guid));
> + memcpy(&driver->dev_type, &dev_type, sizeof(struct hv_guid));
>
>
> /*
^ permalink raw reply
* Re: [PATCH 005/206] Staging: hv: Rename the device type variable
From: Greg KH @ 2011-05-10 12:13 UTC (permalink / raw)
To: Jonathan Cameron
Cc: K. Y. Srinivasan, linux-kernel, devel, virtualization,
Haiyang Zhang, Abhishek Kane
In-Reply-To: <4DC90F37.6010000@cam.ac.uk>
On Tue, May 10, 2011 at 11:11:03AM +0100, Jonathan Cameron wrote:
> On 05/09/11 22:54, K. Y. Srinivasan wrote:
> > Rename the variable g_blk_device_type.
> Why?
Because "g_blk_device_type" is in Hungarian notation, which isn't needed
in the kernel.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 005/206] Staging: hv: Rename the device type variable
From: Jonathan Cameron @ 2011-05-10 12:43 UTC (permalink / raw)
To: Greg KH
Cc: K. Y. Srinivasan, linux-kernel, devel, virtualization,
Haiyang Zhang, Abhishek Kane
In-Reply-To: <20110510121310.GA27396@suse.de>
On 05/10/11 13:13, Greg KH wrote:
> On Tue, May 10, 2011 at 11:11:03AM +0100, Jonathan Cameron wrote:
>> On 05/09/11 22:54, K. Y. Srinivasan wrote:
>>> Rename the variable g_blk_device_type.
>> Why?
>
> Because "g_blk_device_type" is in Hungarian notation, which isn't needed
> in the kernel.
>
Fair enough, I'd misunderstood what g_blk referred to. Sorry for the noise.
^ permalink raw reply
* RE: [PATCH 115/206] Staging: hv: Use completion abstraction in struct netvsc_device
From: KY Srinivasan @ 2011-05-10 12:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
Haiyang Zhang, Abhishek Kane (Mindtree Consulting PVT LTD),
Hank Janssen
In-Reply-To: <20110510070646.GB13847@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Tuesday, May 10, 2011 3:07 AM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; Haiyang Zhang;
> Abhishek Kane (Mindtree Consulting PVT LTD); Hank Janssen
> Subject: Re: [PATCH 115/206] Staging: hv: Use completion abstraction in struct
> netvsc_device
>
> > - net_device->wait_condition = 0;
> > ret = vmbus_sendpacket(device->channel, init_packet,
> > sizeof(struct nvsp_message),
> > (unsigned long)init_packet,
> > @@ -272,10 +272,8 @@ static int netvsc_init_recv_buf(struct hv_device
> *device)
> > goto cleanup;
> > }
> >
> > - wait_event_timeout(net_device->channel_init_wait,
> > - net_device->wait_condition,
> > - msecs_to_jiffies(1000));
> > - BUG_ON(net_device->wait_condition == 0);
> > + t = wait_for_completion_timeout(&net_device->channel_init_wait, HZ);
> > + BUG_ON(t == 0);
>
> I don't think you want a BUG_ON here, but rather fail the
> initialization.
This is existing code and all I did was change the synchronization
primitive used. Back in Feb. when this was done (prior to then), the
wait was indefinite and one of the comments that was
longstanding was that the wait had to be bounded and so these
timed waits were introduced. When this was done,
in some cases, there was no easy way to roll-back state if we did not
get the response within our expected window of time. This is one
such instance where the guest is handing over the receive buffers
(guest physical addresses) to the host. There was a discussion on this very
topic on this mailing list and the consensus was to leave the BUG_ON()
call in cases where we could not reasonably recover.
>
> Also I think you really should add synchronous versions of
> vmbus_sendpacket*, to the vmbus core so that all the synchronous waiting
> can be consolidated into a few helpers instead of needing to opencode
> it everywhere.
True; but having a non-blocking interface at the lowest level gives you
the most flexibility. In addition to this non-blocking interface, we
may want to look at potentially a blocking interface. In the current
code, the blocking primitive that is embedded in a higher level
abstraction is used for a variety of situations including the initial
handshake which is what can be addressed with a synchronous API
at the lowest level.
Regards,
K. Y
^ permalink raw reply
* RE: various vmbus review comments
From: KY Srinivasan @ 2011-05-10 13:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg KH, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110510052425.GA31087@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Tuesday, May 10, 2011 1:24 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: various vmbus review comments
>
> On Mon, May 09, 2011 at 02:56:52PM +0000, KY Srinivasan wrote:
> > I will address this. Greg had a concern about module reference counting
> > and looking at the current code, it did not appear to be an issue. The
> > change you are suggesting will not affect the vmbus core which is what I want
> > to focus on. I will however, fix this issue in the current round of patches I will
> > send out this week.
>
> It very clearly affects the interface between the core and the
> functional drivers. Trying to submit the core without making sure the
> interface is exports works properly is not an overly good idea.
I must be missing something here. As I look at the block driver (and
this is indicative of other drivers as well); the exit routine -
blkvsc_drv_exit, first iterates through all the devices it manages
and invokes device_unregister() on each of the devices and then
invokes vmbus_child_driver_unregister() which is just a wrapper on
driver_unregister(). So, if I understand you correctly, you want the devices to
persist even if there is no driver bound to them. So, if I eliminated the code
that iterates over the devices and unregisters them, that should fix the problem
and I can do this without changing the vmbus core interfaces.
Regards,
K. Y
^ permalink raw reply
* Re: various vmbus review comments
From: Christoph Hellwig @ 2011-05-10 13:07 UTC (permalink / raw)
To: KY Srinivasan
Cc: Christoph Hellwig, Greg KH, gregkh@suse.de,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481EEFF1@TK5EX14MBXC128.redmond.corp.microsoft.com>
> I must be missing something here. As I look at the block driver (and
> this is indicative of other drivers as well); the exit routine -
> blkvsc_drv_exit, first iterates through all the devices it manages
> and invokes device_unregister() on each of the devices and then
> invokes vmbus_child_driver_unregister() which is just a wrapper on
> driver_unregister(). So, if I understand you correctly, you want the devices to
> persist even if there is no driver bound to them. So, if I eliminated the code
> that iterates over the devices and unregisters them, that should fix the problem
> and I can do this without changing the vmbus core interfaces.
If that actually works go for it. But there's no way to know that
without actually implementing and testing it.
^ permalink raw reply
* Re: various vmbus review comments
From: Greg KH @ 2011-05-10 13:16 UTC (permalink / raw)
To: KY Srinivasan
Cc: Christoph Hellwig, Greg KH, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481EEFF1@TK5EX14MBXC128.redmond.corp.microsoft.com>
On Tue, May 10, 2011 at 01:00:26PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:hch@infradead.org]
> > Sent: Tuesday, May 10, 2011 1:24 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; gregkh@suse.de; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > Subject: Re: various vmbus review comments
> >
> > On Mon, May 09, 2011 at 02:56:52PM +0000, KY Srinivasan wrote:
> > > I will address this. Greg had a concern about module reference counting
> > > and looking at the current code, it did not appear to be an issue. The
> > > change you are suggesting will not affect the vmbus core which is what I want
> > > to focus on. I will however, fix this issue in the current round of patches I will
> > > send out this week.
> >
> > It very clearly affects the interface between the core and the
> > functional drivers. Trying to submit the core without making sure the
> > interface is exports works properly is not an overly good idea.
>
> I must be missing something here. As I look at the block driver (and
> this is indicative of other drivers as well); the exit routine -
> blkvsc_drv_exit, first iterates through all the devices it manages
> and invokes device_unregister() on each of the devices and then
> invokes vmbus_child_driver_unregister() which is just a wrapper on
> driver_unregister(). So, if I understand you correctly, you want the devices to
> persist even if there is no driver bound to them.
That's how the Linux driver model should be used, so yes, that is the
correct thing to do.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 00/18] virtio and vhost-net performance enhancements
From: Krishna Kumar2 @ 2011-05-11 17:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: habanero, lguest, Shirley Ma, kvm, Carsten Otte, linux-s390,
Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, Tom Lendacky, netdev, Martin Schwidefsky,
linux390
In-Reply-To: <cover.1304541918.git.mst@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote on 05/05/2011 02:20:18 AM:
> [PATCH 00/18] virtio and vhost-net performance enhancements
>
> OK, here's a large patchset that implements the virtio spec update that I
> sent earlier. It supercedes the PUBLISH_USED_IDX patches
> I sent out earlier.
>
> I know it's a lot to ask but please test, and please consider for
2.6.40 :)
>
> I see nice performance improvements: one run showed going from 12
> to 18 Gbit/s host to guest with netperf, but I did not spend a lot
> of time testing performance, so no guarantees it's not a fluke,
> I hope others will try this out and report.
> Pls note I will be away from keyboard for the next week.
I tested with the git tree (which also contains the later
additional patch), and get this error on guest:
May 11 08:06:08 localhost kernel: net eth0: Unexpected TX queue failure:
-28
May 11 08:06:08 localhost kernel: net eth0: Unexpected TX queue failure:
-28
May 11 08:06:08 localhost kernel: net eth0: Unexpected TX queue failure:
-28
May 11 08:06:08 localhost kernel: net eth0: Unexpected TX queue failure:
-28
...
The network stops after that and requires a modprobe "restart" to
get it working again. This is with the new qemu/vhost/virtio-net.
Please let me know if I am missing something.
thanks,
- KK
^ permalink raw reply
* KVM: Can vlan created in hypervisor and one created inside a VM coexist?
From: Sucheta Chakraborty @ 2011-05-12 7:19 UTC (permalink / raw)
To: virtualization@lists.linux-foundation.org
[-- Attachment #1.1: Type: text/plain, Size: 683 bytes --]
Hi,
Let's say an interface ethX exists.
I created vlan on ethX on hypervisor - ethX.h.
I also created vlan on same ethX inside VM - exthX.v.
Can both ethX.h and ethX.v coexist? - Meaning can both of these interfaces pingable at same time?
Thanks,
Sucheta.
________________________________
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
[-- Attachment #1.2: Type: text/html, Size: 2746 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* KVM: Vlans not working with vlan hw rx acceleration
From: Sucheta Chakraborty @ 2011-05-12 7:20 UTC (permalink / raw)
To: virtualization@lists.linux-foundation.org
[-- Attachment #1.1: Type: text/plain, Size: 796 bytes --]
Hi,
Setup info:
(a) Using RHEL6 kvm. (b) Loaded driver on RHEL6 setup.
(c) Created 2 bridges on top of two interfaces.
(d) Assigned these bridges to 2 VMs.
(e) Created vlans in VMs.
Problem:
When vlan acceleration support is enabled in driver, traffic stops b/w VMs on vlan interfaces inside virtual m/c.
Without, vlan acceleration, everything works fine.
Thanks,
Sucheta.
________________________________
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
[-- Attachment #1.2: Type: text/html, Size: 3204 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] x86, paravirt: Avoid unused by set variables in rdmsr
From: Lucas De Marchi @ 2011-05-12 17:08 UTC (permalink / raw)
To: Andi Kleen, Jeremy Fitzhardinge, Chris Wright, Alok Kataria,
Rusty
Cc: Lucas De Marchi, linux-kernel, virtualization
Just like 5f755293 (x86, gcc-4.6: Avoid unused by set variables in
rdmsr) this patch silences GCC warnings about "set but not used
variables" in paravirt.h.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
---
arch/x86/include/asm/paravirt.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index ebbc4d8..1e02d57 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -147,8 +147,8 @@ static inline int paravirt_wrmsr_regs(u32 *regs)
do { \
int _err; \
u64 _l = paravirt_read_msr(msr, &_err); \
- val1 = (u32)_l; \
- val2 = _l >> 32; \
+ (void)((val1) = (u32)_l); \
+ (void)((val2) = (u32)(_l >> 32)); \
} while (0)
#define wrmsr(msr, val1, val2) \
--
1.7.5.1
^ permalink raw reply related
* Re: [PATCH 06/18] virtio_ring: avail event index interface
From: Michael S. Tsirkin @ 2011-05-15 12:47 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <87aaewh5pg.fsf@rustcorp.com.au>
On Mon, May 09, 2011 at 01:43:15PM +0930, Rusty Russell wrote:
> On Wed, 4 May 2011 23:51:19 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > Define a new feature bit for the host to
> > declare that it uses an avail_event index
> > (like Xen) instead of a feature bit
> > to enable/disable interrupts.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > include/linux/virtio_ring.h | 11 ++++++++---
> > 1 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
> > index f5c1b75..f791772 100644
> > --- a/include/linux/virtio_ring.h
> > +++ b/include/linux/virtio_ring.h
> > @@ -32,6 +32,9 @@
> > /* The Guest publishes the used index for which it expects an interrupt
> > * at the end of the avail ring. Host should ignore the avail->flags field. */
> > #define VIRTIO_RING_F_USED_EVENT_IDX 29
> > +/* The Host publishes the avail index for which it expects a kick
> > + * at the end of the used ring. Guest should ignore the used->flags field. */
> > +#define VIRTIO_RING_F_AVAIL_EVENT_IDX 32
>
> Are you really sure we want to separate the two? Seems a little simpler
> to have one bit to mean "we're publishing our threshold". For someone
> implementing this from scratch, it's a little simpler.
>
> Or are there cases where the old style makes more sense?
>
> Thanks,
> Rusty.
Hmm, it makes debugging easier as each side can disable
publishing separately - I used it all the time when I saw
e.g. networking stuck to guess whether I need to investigate the
interrupt or the exit handling.
But I'm not hung up on this.
Let me know pls.
--
MST
^ permalink raw reply
* Re: [PATCH 08/18] virtio_ring: support for used_event idx feature
From: Michael S. Tsirkin @ 2011-05-15 12:47 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <878vugh5ib.fsf@rustcorp.com.au>
On Mon, May 09, 2011 at 01:47:32PM +0930, Rusty Russell wrote:
> On Wed, 4 May 2011 23:51:38 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > Add support for the used_event idx feature: when enabling
> > interrupts, publish the current avail index value to
> > the host so that we get interrupts on the next update.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > drivers/virtio/virtio_ring.c | 14 ++++++++++++++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index 507d6eb..3a3ed75 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -320,6 +320,14 @@ void *virtqueue_get_buf(struct virtqueue *_vq, unsigned int *len)
> > ret = vq->data[i];
> > detach_buf(vq, i);
> > vq->last_used_idx++;
> > + /* If we expect an interrupt for the next entry, tell host
> > + * by writing event index and flush out the write before
> > + * the read in the next get_buf call. */
> > + if (!(vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)) {
> > + vring_used_event(&vq->vring) = vq->last_used_idx;
> > + virtio_mb();
> > + }
> > +
>
> Hmm, so you're still using the avail->flags; it's just if thresholding
> is enabled the host will ignore it?
>
> It's a little subtle, but it keeps this patch small.
Right, that's exactly why I do it this way.
> Perhaps we'll want to make it more explicit later.
>
> Thanks,
> Rusty.
Yes, e.g. it might be better to avoid touching that cache line,
and track the current status in a private field in the guest.
But I was unable to measure any effect from doing it either way.
--
MST
^ permalink raw reply
* Re: [PATCH 14/18] virtio: add api for delayed callbacks
From: Michael S. Tsirkin @ 2011-05-15 12:48 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <871v08h0vm.fsf@rustcorp.com.au>
On Mon, May 09, 2011 at 03:27:33PM +0930, Rusty Russell wrote:
> On Wed, 4 May 2011 23:52:33 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > Add an API that tells the other side that callbacks
> > should be delayed until a lot of work has been done.
> > Implement using the new used_event feature.
>
> Since you're going to add a capacity query anyway, why not add the
> threshold argument here?
I thought that if we keep the API kind of generic
there might be more of a chance that future transports
will be able to implement it. For example, with an
old host we can't commit to a specific index.
>
> Then the caller can choose how much space it needs. Maybe net and block
> will want different things...
>
> Cheers,
> Rusty.
Hmm, maybe. OK.
--
MST
^ permalink raw reply
* Re: [PATCH 09/18] virtio: use avail_event index
From: Michael S. Tsirkin @ 2011-05-15 13:55 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <874o54h4rt.fsf@rustcorp.com.au>
On Mon, May 09, 2011 at 02:03:26PM +0930, Rusty Russell wrote:
> On Wed, 4 May 2011 23:51:47 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > Use the new avail_event feature to reduce the number
> > of exits from the guest.
>
> Figures here would be nice :)
You mean ASCII art in comments?
> > @@ -228,6 +237,12 @@ add_head:
> > * new available array entries. */
> > virtio_wmb();
> > vq->vring.avail->idx++;
> > + /* If the driver never bothers to kick in a very long while,
> > + * avail index might wrap around. If that happens, invalidate
> > + * kicked_avail index we stored. TODO: make sure all drivers
> > + * kick at least once in 2^16 and remove this. */
> > + if (unlikely(vq->vring.avail->idx == vq->kicked_avail))
> > + vq->kicked_avail_valid = true;
>
> If they don't, they're already buggy. Simply do:
> WARN_ON(vq->vring.avail->idx == vq->kicked_avail);
Hmm, but does it say that somewhere?
It seems that most drivers use locking to prevent
posting more buffers while they drain the used ring,
and also kick at least once in vq->num buffers,
which I guess in the end would work out fine
as vq num is never as large as 2^15.
> > +static bool vring_notify(struct vring_virtqueue *vq)
> > +{
> > + u16 old, new;
> > + bool v;
> > + if (!vq->event)
> > + return !(vq->vring.used->flags & VRING_USED_F_NO_NOTIFY);
> > +
> > + v = vq->kicked_avail_valid;
> > + old = vq->kicked_avail;
> > + new = vq->kicked_avail = vq->vring.avail->idx;
> > + vq->kicked_avail_valid = true;
> > + if (unlikely(!v))
> > + return true;
>
> This is the only place you actually used kicked_avail_valid. Is it
> possible to initialize it in such a way that you can remove this?
If we kill the code above as you suggested, likely yes.
Maybe an explicit flag is more obvious?
> > @@ -482,6 +517,8 @@ void vring_transport_features(struct virtio_device *vdev)
> > break;
> > case VIRTIO_RING_F_USED_EVENT_IDX:
> > break;
> > + case VIRTIO_RING_F_AVAIL_EVENT_IDX:
> > + break;
> > default:
> > /* We don't understand this bit. */
> > clear_bit(i, vdev->features);
>
> Does this belong in a prior patch?
>
> Thanks,
> Rusty.
Well if we don't support the feature in the ring we should not
ack the feature, right?
^ permalink raw reply
* Re: [PATCH 06/18] virtio_ring: avail event index interface
From: Rusty Russell @ 2011-05-16 6:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <20110515124727.GA24932@redhat.com>
On Sun, 15 May 2011 15:47:27 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, May 09, 2011 at 01:43:15PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:51:19 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > #define VIRTIO_RING_F_USED_EVENT_IDX 29
> > > +/* The Host publishes the avail index for which it expects a kick
> > > + * at the end of the used ring. Guest should ignore the used->flags field. */
> > > +#define VIRTIO_RING_F_AVAIL_EVENT_IDX 32
> >
> > Are you really sure we want to separate the two? Seems a little simpler
> > to have one bit to mean "we're publishing our threshold". For someone
> > implementing this from scratch, it's a little simpler.
> >
> > Or are there cases where the old style makes more sense?
> >
> > Thanks,
> > Rusty.
>
> Hmm, it makes debugging easier as each side can disable
> publishing separately - I used it all the time when I saw
> e.g. networking stuck to guess whether I need to investigate the
> interrupt or the exit handling.
>
> But I'm not hung up on this.
>
> Let me know pls.
If we combine them into one, then these patches no longer depend on
the feature bit expansion, which is worthwhile (though I'll take both).
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 09/18] virtio: use avail_event index
From: Rusty Russell @ 2011-05-16 7:12 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <20110515135541.GF24932@redhat.com>
On Sun, 15 May 2011 16:55:41 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, May 09, 2011 at 02:03:26PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:51:47 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > Use the new avail_event feature to reduce the number
> > > of exits from the guest.
> >
> > Figures here would be nice :)
>
> You mean ASCII art in comments?
I mean benchmarks of some kind.
>
> > > @@ -228,6 +237,12 @@ add_head:
> > > * new available array entries. */
> > > virtio_wmb();
> > > vq->vring.avail->idx++;
> > > + /* If the driver never bothers to kick in a very long while,
> > > + * avail index might wrap around. If that happens, invalidate
> > > + * kicked_avail index we stored. TODO: make sure all drivers
> > > + * kick at least once in 2^16 and remove this. */
> > > + if (unlikely(vq->vring.avail->idx == vq->kicked_avail))
> > > + vq->kicked_avail_valid = true;
> >
> > If they don't, they're already buggy. Simply do:
> > WARN_ON(vq->vring.avail->idx == vq->kicked_avail);
>
> Hmm, but does it say that somewhere?
AFAICT it's a corollary of:
1) You have a finite ring of size <= 2^16.
2) You need to kick the other side once you've done some work.
> > > @@ -482,6 +517,8 @@ void vring_transport_features(struct virtio_device *vdev)
> > > break;
> > > case VIRTIO_RING_F_USED_EVENT_IDX:
> > > break;
> > > + case VIRTIO_RING_F_AVAIL_EVENT_IDX:
> > > + break;
> > > default:
> > > /* We don't understand this bit. */
> > > clear_bit(i, vdev->features);
> >
> > Does this belong in a prior patch?
> >
> > Thanks,
> > Rusty.
>
> Well if we don't support the feature in the ring we should not
> ack the feature, right?
Ah, you're right.
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 14/18] virtio: add api for delayed callbacks
From: Rusty Russell @ 2011-05-16 7:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <20110515124818.GD24932@redhat.com>
On Sun, 15 May 2011 15:48:18 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, May 09, 2011 at 03:27:33PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:52:33 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > Add an API that tells the other side that callbacks
> > > should be delayed until a lot of work has been done.
> > > Implement using the new used_event feature.
> >
> > Since you're going to add a capacity query anyway, why not add the
> > threshold argument here?
>
> I thought that if we keep the API kind of generic
> there might be more of a chance that future transports
> will be able to implement it. For example, with an
> old host we can't commit to a specific index.
No, it's always a hint anyway: you can be notified before the threshold
is reached. But best make it explicit I think.
Cheers,
Rusty.
^ permalink raw reply
* Re: KVM Forum 2011: Call For Participation
From: Dor Laor @ 2011-05-16 14:12 UTC (permalink / raw)
To: KVM-Forum-2011-PC
Cc: libvir-list, linux-kernel, qemu-devel, kvm, virtualization
In-Reply-To: <20110421172155.GE3591@x200.localdomain>
The abstract submission deadline was originally set for today.
The forum committee agreed to extend the deadline period until next
Sunday, May 22.
The notification date remains the same (May 31).
Thanks,
your KVM Forum 2011 Program Committee
On 04/21/2011 08:21 PM, KVM-Forum-2011-PC@redhat.com wrote:
> =================================================================
> KVM Forum 2011: Call For Participation
> August 15-16, 2011 - Hyatt Regency Vancouver - Vancouver, Canada
> =================================================================
>
> KVM is an industry leading open source hypervisor that provides an ideal
> platform for datacenter virtualization, virtual desktop infrastructure,
> and cloud computing. Once again, it's time to bring together the
> community of developers and users that define the KVM ecosystem for
> our annual technical conference. We will discuss the current state of
> affairs and plan for the future of KVM, its surrounding infrastructure,
> and management tools. So mark your calendar and join us in advancing KVM.
>
> http://events.linuxfoundation.org/events/kvm-forum/
>
> We are colocated with The Linux Foundation's LinuxCon again this year.
> KVM Forum attendees will be eligible to attend LinuxCon for a discounted
> rate.
>
> http://events.linuxfoundation.org/events/kvm-forum/register
>
> We invite you to lead part of the discussion by submitting a speaking
> proposal for KVM Forum 2011.
>
> http://events.linuxfoundation.org/cfp
>
> Suggested topics:
>
> KVM
> - Scaling and performance
> - Nested virtualization
> - I/O improvements
> - PCI device assignment
> - Driver domains
> - Time keeping
> - Resource management (cpu, memory, i/o)
> - Memory management (page sharing, swapping, huge pages, etc)
> - Fault tolerance
> - VEPA, VN-Link, vswitch
> - Security
>
> QEMU
> - Device model improvements
> - New devices
> - Scaling and performance
> - Desktop virtualization
> - Spice
> - Increasing robustness and hardening
> - Security model
> - Management interfaces
> - QMP protocol and implementation
> - Image formats
> - Live migration
> - Live snapshots and merging
>
> Virtio
> - Speeding up existing devices
> - Alternatives
> - Virtio on non-Linux
>
> Management infrastructure
> - Libvirt
> - KVM autotest
> - OpenStack
> - Network virtualization management
> - Enterprise storage management
>
> Cloud computing
> - Scalable storage
> - Virtual networking
> - Security
> - Provisioning
> - Hybrid
>
> SUBMISSION REQUIREMENTS
>
> Abstracts due: May 16th, 2011
> Notification: May 31th, 2011
>
> Please submit a short abstract (~150 words) describing your presentation
> proposal. In your submission please note how long your talk will take.
> Slots vary in length up to 45 minutes. Also include in your proposal
> the proposal type -- one of:
>
> - technical talk
> - end-user talk
> - BOF (birds of a feather) session
>
> Sumbit your proposal here:
>
> http://events.linuxfoundation.org/cfp
>
> You will receive a notification whether or not your presentation proposal
> was accepted by May 31st.
>
> END-USER COLLABORATION
>
> One of the big challenges as developers is to know what, where and how
> people actually use our software. We will reserve a few slots for end
> users talking about their deployment challenges and achievements.
>
> If you are using KVM in production you are encouraged submit a speaking
> proposal. Simply mark it as an end-user collaboration proposal. As and
> end user, this is a unique opportunity to get your input to developers.
>
> BOF SESSION
>
> We will reserve some slots in the evening after the main conference
> tracks, for birds of a feather sessions. These sessions will be less
> formal than presentation tracks and targetted for people who would
> like to discuss specific issues with other developers and/or users.
> If you are interested in getting developers and/or uses together to
> discuss a specific problem, please submit a BOF proposal.
>
> LIGHTNING TALKS
>
> In addition to submitted talks we will also have some room for lightning
> talks. These are short (5 minute) discussions to highlight new work or
> ideas that aren't complete enough to warrant a full presentation slot.
> Lightning talk submissions and scheduling will be handled on-site at
> KVM Forum.
>
> HOTEL / TRAVEL
>
> The KVM Forum 2011 will be held in Vancouver BC at the Hyatt Regency
> Vancouver.
>
> http://events.linuxfoundation.org/events/kvm-forum/travel
>
> Thank you for your interest in KVM. We're looking forward to your
> submissions and seeing you at the KVM Forum 2011 in August!
>
> Thanks,
> your KVM Forum 2011 Program Commitee
>
> Please contact us with any questions or comments.
> KVM-Forum-2011-PC@redhat.com
>
> _______________________________________________
> Kvm-forum-2011-pc mailing list
> Kvm-forum-2011-pc@redhat.com
> https://www.redhat.com/mailman/listinfo/kvm-forum-2011-pc
^ permalink raw reply
* Unattended Linux VM Configuration Tool for Hyper-V
From: yusuf öztürk @ 2011-05-16 14:47 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 1040 bytes --]
Hello,
I've announced a new tool for Hyper-V called "Set-LinuxVM".
What you can do with “Set-LinuxVM”:
*1)* Unattended IP, Hostname and DNS configuration for Linux VMs.
*2)* Automatic Linux integration components installation.
*3)* Multi Distro Support: Debian, Ubuntu, Centos, Fedora, Redhat and Suse!
*4)* Automatic CPanel installation for Redhat and Centos
*5)* Linux VM Template support (Use Skip for EnableLIC switch)
*6)* Hyper-V support! You don’t need SCVMM to use this script.
*7)* Multiple Hyper-V and SCVMM host support.
*8)* Automatic Emulated NIC to Synthetic NIC support.
*9)* No need to internet connection (SSH access etc.) or additional changes
on VM.
*10)* Custom Answer File support! You can execute your own scripts.
I made several tests on different distros. I think this is an important era
for Hyper-V about Linux Virtualization functionality.
You can check:
http://www.yusufozturk.info/virtual-machine-manager/unattended-linux-vm-configuration-tool-for-hyper-v.html
Regards,
Yusuf.
[-- Attachment #1.2: Type: text/html, Size: 2789 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 06/18] virtio_ring: avail event index interface
From: Michael S. Tsirkin @ 2011-05-17 6:00 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <87k4drduzs.fsf@rustcorp.com.au>
On Mon, May 16, 2011 at 03:53:19PM +0930, Rusty Russell wrote:
> On Sun, 15 May 2011 15:47:27 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Mon, May 09, 2011 at 01:43:15PM +0930, Rusty Russell wrote:
> > > On Wed, 4 May 2011 23:51:19 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > #define VIRTIO_RING_F_USED_EVENT_IDX 29
> > > > +/* The Host publishes the avail index for which it expects a kick
> > > > + * at the end of the used ring. Guest should ignore the used->flags field. */
> > > > +#define VIRTIO_RING_F_AVAIL_EVENT_IDX 32
> > >
> > > Are you really sure we want to separate the two? Seems a little simpler
> > > to have one bit to mean "we're publishing our threshold". For someone
> > > implementing this from scratch, it's a little simpler.
> > >
> > > Or are there cases where the old style makes more sense?
> > >
> > > Thanks,
> > > Rusty.
> >
> > Hmm, it makes debugging easier as each side can disable
> > publishing separately - I used it all the time when I saw
> > e.g. networking stuck to guess whether I need to investigate the
> > interrupt or the exit handling.
> >
> > But I'm not hung up on this.
> >
> > Let me know pls.
>
> If we combine them into one, then these patches no longer depend on
> the feature bit expansion, which is worthwhile (though I'll take both).
>
> Thanks,
> Rusty.
Yes, I know. But if we do expand feature bits anyway, for debugging
and profiling if nothing else it's useful to have them separate ...
If you take both why does the order matter?
--
MST
^ permalink raw reply
* Re: [PATCH 09/18] virtio: use avail_event index
From: Michael S. Tsirkin @ 2011-05-17 6:10 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, lguest, Shirley Ma, kvm, linux-s390,
netdev, habanero, Heiko Carstens, linux-kernel, virtualization,
steved, Christian Borntraeger, Tom Lendacky, Martin Schwidefsky,
linux390
In-Reply-To: <87ei3zdsq2.fsf@rustcorp.com.au>
On Mon, May 16, 2011 at 04:42:21PM +0930, Rusty Russell wrote:
> On Sun, 15 May 2011 16:55:41 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Mon, May 09, 2011 at 02:03:26PM +0930, Rusty Russell wrote:
> > > On Wed, 4 May 2011 23:51:47 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > Use the new avail_event feature to reduce the number
> > > > of exits from the guest.
> > >
> > > Figures here would be nice :)
> >
> > You mean ASCII art in comments?
>
> I mean benchmarks of some kind.
:)
> >
> > > > @@ -228,6 +237,12 @@ add_head:
> > > > * new available array entries. */
> > > > virtio_wmb();
> > > > vq->vring.avail->idx++;
> > > > + /* If the driver never bothers to kick in a very long while,
> > > > + * avail index might wrap around. If that happens, invalidate
> > > > + * kicked_avail index we stored. TODO: make sure all drivers
> > > > + * kick at least once in 2^16 and remove this. */
> > > > + if (unlikely(vq->vring.avail->idx == vq->kicked_avail))
> > > > + vq->kicked_avail_valid = true;
> > >
> > > If they don't, they're already buggy. Simply do:
> > > WARN_ON(vq->vring.avail->idx == vq->kicked_avail);
> >
> > Hmm, but does it say that somewhere?
>
> AFAICT it's a corollary of:
> 1) You have a finite ring of size <= 2^16.
> 2) You need to kick the other side once you've done some work.
Well one can imagine a driver doing:
while (virtqueue_get_buf()) {
virtqueue_add_buf()
}
virtqueue_kick()
which looks sensible (batch kicks) but might
process any number of bufs between kicks.
If we look at drivers closely enough, I think none
of them do the equivalent of the above, but not 100% sure.
> > > > @@ -482,6 +517,8 @@ void vring_transport_features(struct virtio_device *vdev)
> > > > break;
> > > > case VIRTIO_RING_F_USED_EVENT_IDX:
> > > > break;
> > > > + case VIRTIO_RING_F_AVAIL_EVENT_IDX:
> > > > + break;
> > > > default:
> > > > /* We don't understand this bit. */
> > > > clear_bit(i, vdev->features);
> > >
> > > Does this belong in a prior patch?
> > >
> > > Thanks,
> > > Rusty.
> >
> > Well if we don't support the feature in the ring we should not
> > ack the feature, right?
>
> Ah, you're right.
>
> Thanks,
> Rusty.
^ permalink raw reply
* Re: [PATCH 3/3] powerpc-virtio: virtio support introduced (block, network, serial, balloon, 9p-fs), both fullemu and power-kvm
From: Alexander Graf @ 2011-05-17 7:06 UTC (permalink / raw)
To: David Gibson
Cc: Michael S. Tsirkin, Alexey Kardashevskiy, Benjamin Herrenschmidt,
qemu-devel@nongnu.org Developers, virtualization, Paul Mackerras
In-Reply-To: <1305614826-1815-4-git-send-email-david@gibson.dropbear.id.au>
On 17.05.2011, at 08:47, David Gibson wrote:
> From: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> The recently added pseries machine does not currently support PCI
> emulation. For the (upcoming) kvm case, this is quite difficult to do
> because the preferred HV mode for the host kernel does not allow MMIO
> emulation (a hardware limitation).
>
> Therefore, to support virtio devices, we implement a new virtio setup
> protocol for PAPR guests. This is based loosely on the s390 and lguest
> methods, using the PAPR hcalls for the virtio primitive operations,
> and the PAPR device tree to advertise the virtio device resources to the
> guest.
>
> This patch includes support for the virtio block, network, serial, and
> balloon devices, and the 9p filesystem.
>
> The guest linux kernel should be updated as well in order to
> support a new virtio setup.
>
> Supported devices are (below are QEMU command line switches):
>
> - virtio-blk - block device, at the moment works as "IDE":
> usage: -drive file=test-virtio-blk.img,if=ide
>
> - virtio-net - network device
> usage: -net nic,model=virtio-net
>
> - virtio-balloon - memory hot-swap device (at the moment of commit, power-kvm
> did not support balloon)
> usage: -device virtio-balloon-spapr
>
> - virtio-serial - serial bus controller
> usage: -device virtio-serial-spapr \
> -chardev socket,id=CONSOLE,host=localhost,port=4444,server,telnet \
> -device virtconsole,chardev=CONSOLE
> The first switch tells QEMU to create a serial bus device and next
> 2 switches create "chardev" and virtual console device connected to
> that "chardev".
>
> - virtio-9p - plan9 filesystem with ability to work over virtio transport
> usage: -fsdev fstype=local,id=TAG,path=/home/aik/,security_model=none \
> -device virtio-9p-spapr,fsdev=TAG,mount_tag=TAG
> where TAG is a tag which should be used later when mounting is linux as:
> mount -t 9p -o trans=virtio TAG /mnt
>
> Configure for full emulation as:
> ./configure --target-list=ppc64-softmmu --enable-attr
>
> Configure for power-kvm as:
> ./configure --enable-kvm --target-list=ppc64-softmmu --enable-fdt \
> --cc="gcc -m64" \
> --kerneldir=/root/kheaders --enable-io-thread --enable-attr
>
> Note: --enable-attr is required for 9p support. On ppc64 systems, libattr
> should be compiled and installed manually as it is not distributes in
> 64bit packages.
Before including such a patch, we should really discuss the desired interface for virtio on sPAPR. I personally would prefer if we could have a generic MMIO hypercall that the guest issues, so that we can simply use virtio-pci on sPAPR (and all the other PCI hardware).
But at the end of the day, the steps should be as follows:
1) Discuss this on the virtualization ML
2) Send patches for the virtio documentation so the protocol has a spec (which we're lacking for s390 still)
3) Implement Linux side, upstream it
4) Upstream Qemu side
Since I haven't seen 1-3, I'd like to defer this patch until the other points are good :)
Alex
^ permalink raw reply
* Re: [PATCH 09/18] virtio: use avail_event index
From: Tom Lendacky @ 2011-05-17 16:23 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, linux-s390, lguest, Shirley Ma, kvm,
Michael S. Tsirkin, netdev, habanero, Heiko Carstens,
linux-kernel, virtualization, steved, Christian Borntraeger,
Martin Schwidefsky, linux390
In-Reply-To: <87ei3zdsq2.fsf@rustcorp.com.au>
On Monday, May 16, 2011 02:12:21 AM Rusty Russell wrote:
> On Sun, 15 May 2011 16:55:41 +0300, "Michael S. Tsirkin" <mst@redhat.com>
wrote:
> > On Mon, May 09, 2011 at 02:03:26PM +0930, Rusty Russell wrote:
> > > On Wed, 4 May 2011 23:51:47 +0300, "Michael S. Tsirkin" <mst@redhat.com>
wrote:
> > > > Use the new avail_event feature to reduce the number
> > > > of exits from the guest.
> > >
> > > Figures here would be nice :)
> >
> > You mean ASCII art in comments?
>
> I mean benchmarks of some kind.
I'm working on getting some benchmark results for the patches. I should
hopefully have something in the next day or two.
Tom
>
> > > > @@ -228,6 +237,12 @@ add_head:
> > > > * new available array entries. */
> > > >
> > > > virtio_wmb();
> > > > vq->vring.avail->idx++;
> > > >
> > > > + /* If the driver never bothers to kick in a very long while,
> > > > + * avail index might wrap around. If that happens, invalidate
> > > > + * kicked_avail index we stored. TODO: make sure all drivers
> > > > + * kick at least once in 2^16 and remove this. */
> > > > + if (unlikely(vq->vring.avail->idx == vq->kicked_avail))
> > > > + vq->kicked_avail_valid = true;
> > >
> > > If they don't, they're already buggy. Simply do:
> > > WARN_ON(vq->vring.avail->idx == vq->kicked_avail);
> >
> > Hmm, but does it say that somewhere?
>
> AFAICT it's a corollary of:
> 1) You have a finite ring of size <= 2^16.
> 2) You need to kick the other side once you've done some work.
>
> > > > @@ -482,6 +517,8 @@ void vring_transport_features(struct
> > > > virtio_device *vdev)
> > > >
> > > > break;
> > > >
> > > > case VIRTIO_RING_F_USED_EVENT_IDX:
> > > > break;
> > > >
> > > > + case VIRTIO_RING_F_AVAIL_EVENT_IDX:
> > > > + break;
> > > >
> > > > default:
> > > > /* We don't understand this bit. */
> > > > clear_bit(i, vdev->features);
> > >
> > > Does this belong in a prior patch?
> > >
> > > Thanks,
> > > Rusty.
> >
> > Well if we don't support the feature in the ring we should not
> > ack the feature, right?
>
> Ah, you're right.
>
> Thanks,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] Connector: Set the CN_NETLINK_USERS correctly
From: K. Y. Srinivasan @ 2011-05-17 22:25 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization; +Cc: K. Y. Srinivasan
The CN_NETLINK_USERS must be set to the highest valid index +1.
Thanks to Evgeniy for pointing this out.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
include/linux/connector.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/connector.h b/include/linux/connector.h
index 7c60d09..f696bcc 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -44,7 +44,7 @@
#define CN_VAL_DRBD 0x1
#define CN_KVP_IDX 0x9 /* HyperV KVP */
-#define CN_NETLINK_USERS 9
+#define CN_NETLINK_USERS 10 /* Highest index + 1 */
/*
* Maximum connector's message size.
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox