* Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
From: Michael S. Tsirkin @ 2011-12-04 12:01 UTC (permalink / raw)
To: Avi Kivity; +Cc: markmc, kvm, linux-kernel, virtualization, Sasha Levin
In-Reply-To: <4EDB5EF0.2010909@redhat.com>
On Sun, Dec 04, 2011 at 01:52:16PM +0200, Avi Kivity wrote:
> On 12/03/2011 01:50 PM, Sasha Levin wrote:
> > On Fri, 2011-12-02 at 11:16 +1030, Rusty Russell wrote:
> > > On Thu, 1 Dec 2011 12:26:42 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> > > > > On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > > > > > We'll presumably need some logic to increment is back,
> > > > > > to account for random workload changes.
> > > > > > Something like slow start?
> > > > >
> > > > > We can increment it each time the queue was less than 10% full, it
> > > > > should act like slow start, no?
> > > >
> > > > No, we really shouldn't get an empty ring as long as things behave
> > > > well. What I meant is something like:
> > >
> > > I was thinking of the network output case, but you're right. We need to
> > > distinguish between usually full (eg. virtio-net input) and usually
> > > empty (eg. virtio-net output).
> > >
> > > The signal for "we to pack more into the ring" is different. We could
> > > use some hacky heuristic like "out == 0" but I'd rather make it explicit
> > > when we set up the virtqueue.
> > >
> > > Our other alternative, moving the logic to the driver, is worse.
> > >
> > > As to fading the effect over time, that's harder. We have to deplete
> > > the ring quite a few times before it turns into always-indirect. We
> > > could back off every time the ring is totally idle, but that may hurt
> > > bursty traffic. Let's try simple first?
> >
> > I tried to take a different approach, and tried putting the indirect
> > descriptors in a kmem_cache as Michael suggested. The benchmarks showed
> > that this way virtio-net actually worked faster with indirect on even in
> > a single stream.
>
> How much better?
>
> I think that if indirects benefit networking, then we're doing something
> wrong. What's going on? Does the ring get filled too early? If so we
> should expand it.
The ring is physically contigious.
With 256 entries and 64 bytes each, that's already 16K.
> --
> error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
From: Avi Kivity @ 2011-12-04 11:52 UTC (permalink / raw)
To: Sasha Levin; +Cc: markmc, kvm, Michael S. Tsirkin, linux-kernel, virtualization
In-Reply-To: <1322913028.3782.4.camel@lappy>
On 12/03/2011 01:50 PM, Sasha Levin wrote:
> On Fri, 2011-12-02 at 11:16 +1030, Rusty Russell wrote:
> > On Thu, 1 Dec 2011 12:26:42 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> > > > On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > > > > We'll presumably need some logic to increment is back,
> > > > > to account for random workload changes.
> > > > > Something like slow start?
> > > >
> > > > We can increment it each time the queue was less than 10% full, it
> > > > should act like slow start, no?
> > >
> > > No, we really shouldn't get an empty ring as long as things behave
> > > well. What I meant is something like:
> >
> > I was thinking of the network output case, but you're right. We need to
> > distinguish between usually full (eg. virtio-net input) and usually
> > empty (eg. virtio-net output).
> >
> > The signal for "we to pack more into the ring" is different. We could
> > use some hacky heuristic like "out == 0" but I'd rather make it explicit
> > when we set up the virtqueue.
> >
> > Our other alternative, moving the logic to the driver, is worse.
> >
> > As to fading the effect over time, that's harder. We have to deplete
> > the ring quite a few times before it turns into always-indirect. We
> > could back off every time the ring is totally idle, but that may hurt
> > bursty traffic. Let's try simple first?
>
> I tried to take a different approach, and tried putting the indirect
> descriptors in a kmem_cache as Michael suggested. The benchmarks showed
> that this way virtio-net actually worked faster with indirect on even in
> a single stream.
How much better?
I think that if indirects benefit networking, then we're doing something
wrong. What's going on? Does the ring get filled too early? If so we
should expand it.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
From: Michael S. Tsirkin @ 2011-12-04 11:06 UTC (permalink / raw)
To: Sasha Levin; +Cc: markmc, kvm, linux-kernel, virtualization, Avi Kivity
In-Reply-To: <1322913028.3782.4.camel@lappy>
On Sat, Dec 03, 2011 at 01:50:28PM +0200, Sasha Levin wrote:
> On Fri, 2011-12-02 at 11:16 +1030, Rusty Russell wrote:
> > On Thu, 1 Dec 2011 12:26:42 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> > > > On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > > > > We'll presumably need some logic to increment is back,
> > > > > to account for random workload changes.
> > > > > Something like slow start?
> > > >
> > > > We can increment it each time the queue was less than 10% full, it
> > > > should act like slow start, no?
> > >
> > > No, we really shouldn't get an empty ring as long as things behave
> > > well. What I meant is something like:
> >
> > I was thinking of the network output case, but you're right. We need to
> > distinguish between usually full (eg. virtio-net input) and usually
> > empty (eg. virtio-net output).
> >
> > The signal for "we to pack more into the ring" is different. We could
> > use some hacky heuristic like "out == 0" but I'd rather make it explicit
> > when we set up the virtqueue.
> >
> > Our other alternative, moving the logic to the driver, is worse.
> >
> > As to fading the effect over time, that's harder. We have to deplete
> > the ring quite a few times before it turns into always-indirect. We
> > could back off every time the ring is totally idle, but that may hurt
> > bursty traffic. Let's try simple first?
>
> I tried to take a different approach, and tried putting the indirect
> descriptors in a kmem_cache as Michael suggested. The benchmarks showed
> that this way virtio-net actually worked faster with indirect on even in
> a single stream.
>
> Maybe we can do that instead of playing with threshold for now.
>
> The question here, how much wasted space we can afford? since indirect
> descriptors would have to be the same size we'd have a bunch of them
> wasted in the cache. Ofcourse we can make that configurable, but how
> much is ok by default?
I think it's a good idea to make that per-device.
For network at least, each skb already has overhead of
around 1/2 K, so using up to 1/2K more seems acceptable.
But even if we went up to MAX_SKB_FRAGS+2, it would be
only 1K per ring entry, so for a ring of 256 entries, we end up with
256K max waste. That's not that terrible.
But I'd say let's do some benchmarking to figure out
the point where the gains are becoming very small.
> --
>
> Sasha.
^ permalink raw reply
* Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
From: Sasha Levin @ 2011-12-03 11:50 UTC (permalink / raw)
To: Rusty Russell
Cc: markmc, kvm, Michael S. Tsirkin, linux-kernel, virtualization,
Avi Kivity
In-Reply-To: <87zkfbre9x.fsf@rustcorp.com.au>
On Fri, 2011-12-02 at 11:16 +1030, Rusty Russell wrote:
> On Thu, 1 Dec 2011 12:26:42 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> > > On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > > > We'll presumably need some logic to increment is back,
> > > > to account for random workload changes.
> > > > Something like slow start?
> > >
> > > We can increment it each time the queue was less than 10% full, it
> > > should act like slow start, no?
> >
> > No, we really shouldn't get an empty ring as long as things behave
> > well. What I meant is something like:
>
> I was thinking of the network output case, but you're right. We need to
> distinguish between usually full (eg. virtio-net input) and usually
> empty (eg. virtio-net output).
>
> The signal for "we to pack more into the ring" is different. We could
> use some hacky heuristic like "out == 0" but I'd rather make it explicit
> when we set up the virtqueue.
>
> Our other alternative, moving the logic to the driver, is worse.
>
> As to fading the effect over time, that's harder. We have to deplete
> the ring quite a few times before it turns into always-indirect. We
> could back off every time the ring is totally idle, but that may hurt
> bursty traffic. Let's try simple first?
I tried to take a different approach, and tried putting the indirect
descriptors in a kmem_cache as Michael suggested. The benchmarks showed
that this way virtio-net actually worked faster with indirect on even in
a single stream.
Maybe we can do that instead of playing with threshold for now.
The question here, how much wasted space we can afford? since indirect
descriptors would have to be the same size we'd have a bunch of them
wasted in the cache. Ofcourse we can make that configurable, but how
much is ok by default?
--
Sasha.
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Ohad Ben-Cohen @ 2011-12-03 6:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kvm, Michael S. Tsirkin, linux-kernel, virtualization,
linux-arm-kernel
In-Reply-To: <1322867384.11728.20.camel@pasglop>
On Sat, Dec 3, 2011 at 1:09 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Have you measured the impact of using normal barriers (non-SMP ones)
> like we use on normal HW drivers unconditionally ?
>
> IE. If the difference is small enough I'd say just go for it and avoid
> the bloat.
I agree.
MST wanted to give this a try this week. If all goes well and there's
no unreasonable regression, we'd just switch to mandatory barriers.
Ohad.
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Rusty Russell @ 2011-12-03 5:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Ohad Ben-Cohen
Cc: linux-arm-kernel, Michael S. Tsirkin, linux-kernel, kvm,
virtualization
In-Reply-To: <1322867384.11728.20.camel@pasglop>
On Sat, 03 Dec 2011 10:09:44 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Tue, 2011-11-29 at 14:31 +0200, Ohad Ben-Cohen wrote:
> > A trivial, albeit sub-optimal, solution would be to simply revert
> > commit d57ed95 "virtio: use smp_XX barriers on SMP". Obviously, though,
> > that's going to have a negative impact on performance of SMP-based
> > virtualization use cases.
>
> Have you measured the impact of using normal barriers (non-SMP ones)
> like we use on normal HW drivers unconditionally ?
>
> IE. If the difference is small enough I'd say just go for it and avoid
> the bloat.
Yep. Plan is:
1) Measure the difference.
2) Difference unmeassurable? Use normal barriers (ie. revert d57ed95).
3) Difference small? Revert d57ed95 for 3.2, revisit for 3.3.
4) Difference large? Runtime switch based on "if you're PCI" for 3.2,
revisit for 3.3.
Cheers,
Rusty.
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Benjamin Herrenschmidt @ 2011-12-02 23:09 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: kvm, Michael S. Tsirkin, linux-kernel, virtualization,
linux-arm-kernel
In-Reply-To: <1322569886-13055-1-git-send-email-ohad@wizery.com>
On Tue, 2011-11-29 at 14:31 +0200, Ohad Ben-Cohen wrote:
> Virtio is using memory barriers to control the ordering of
> references to the vrings on SMP systems. When the guest is compiled
> with SMP support, virtio is only using SMP barriers in order to
> avoid incurring the overhead involved with mandatory barriers.
>
> Lately, though, virtio is being increasingly used with inter-processor
> communication scenarios too, which involve running two (separate)
> instances of operating systems on two (separate) processors, each of
> which might either be UP or SMP.
>
> To control the ordering of memory references when the vrings are shared
> between two external processors, we must always use mandatory barriers.
>
> A trivial, albeit sub-optimal, solution would be to simply revert
> commit d57ed95 "virtio: use smp_XX barriers on SMP". Obviously, though,
> that's going to have a negative impact on performance of SMP-based
> virtualization use cases.
Have you measured the impact of using normal barriers (non-SMP ones)
like we use on normal HW drivers unconditionally ?
IE. If the difference is small enough I'd say just go for it and avoid
the bloat.
Ben.
^ permalink raw reply
* RE: [PATCH 1/1] hv: Update MAINTAINERS
From: KY Srinivasan @ 2011-12-02 15:35 UTC (permalink / raw)
To: Sasha Levin, Jiri Kosina
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, joe@perches.com, dmitry.torokhov@gmail.com,
Haiyang Zhang
In-Reply-To: <1322836693.3780.7.camel@lappy>
> -----Original Message-----
> From: Sasha Levin [mailto:levinsasha928@gmail.com]
> Sent: Friday, December 02, 2011 9:38 AM
> To: Jiri Kosina
> Cc: KY Srinivasan; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; ohering@suse.com;
> joe@perches.com; dmitry.torokhov@gmail.com; Haiyang Zhang
> Subject: Re: [PATCH 1/1] hv: Update MAINTAINERS
>
> On Fri, 2011-12-02 at 15:31 +0100, Jiri Kosina wrote:
> > On Thu, 1 Dec 2011, K. Y. Srinivasan wrote:
> >
> > > Update the MAINTAINERS file to reflect the current state
> > > of the Hyper-V drivers.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > ---
> > > MAINTAINERS | 16 ++++++++++------
> > > 1 files changed, 10 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 3523ab0..809cad8 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -3197,6 +3197,16 @@ M: William Irwin <wli@holomorphy.com>
> > > S: Maintained
> > > F: fs/hugetlbfs/
> > >
> > > +Hyper-V CORE AND DRIVERS
> > > +M: K. Y. Srinivasan <kys@microsoft.com>
> > > +M: Haiyang Zhang <haiyangz@microsoft.com>
> > > +L: devel@linuxdriverproject.org
> > > +S: Maintained
> > > +F: drivers/hv/
> > > +F: drivers/hid/hid-hyperv.c
> > > +F: drivers/net/hyperv/
> > > +F: drivers/staging/hv/
> > > +
> >
> > I will be taking this through trivial tree. Thanks,
>
> It should probably be 'S: Supported' though, right?
You are right.
K. Y
>
> --
>
> Sasha.
>
^ permalink raw reply
* RE: [PATCH 1/1] hv: Update MAINTAINERS
From: KY Srinivasan @ 2011-12-02 14:38 UTC (permalink / raw)
To: Jiri Kosina
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, joe@perches.com, dmitry.torokhov@gmail.com,
Haiyang Zhang
In-Reply-To: <alpine.LNX.2.00.1112021531230.18207@pobox.suse.cz>
> -----Original Message-----
> From: Jiri Kosina [mailto:jkosina@suse.cz]
> Sent: Friday, December 02, 2011 9:32 AM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; ohering@suse.com;
> joe@perches.com; dmitry.torokhov@gmail.com; Haiyang Zhang
> Subject: Re: [PATCH 1/1] hv: Update MAINTAINERS
>
> On Thu, 1 Dec 2011, K. Y. Srinivasan wrote:
>
> > Update the MAINTAINERS file to reflect the current state
> > of the Hyper-V drivers.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> > MAINTAINERS | 16 ++++++++++------
> > 1 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3523ab0..809cad8 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3197,6 +3197,16 @@ M: William Irwin <wli@holomorphy.com>
> > S: Maintained
> > F: fs/hugetlbfs/
> >
> > +Hyper-V CORE AND DRIVERS
> > +M: K. Y. Srinivasan <kys@microsoft.com>
> > +M: Haiyang Zhang <haiyangz@microsoft.com>
> > +L: devel@linuxdriverproject.org
> > +S: Maintained
> > +F: drivers/hv/
> > +F: drivers/hid/hid-hyperv.c
> > +F: drivers/net/hyperv/
> > +F: drivers/staging/hv/
> > +
>
> I will be taking this through trivial tree. Thanks,
Thank you!
K. Y
^ permalink raw reply
* Re: [PATCH 1/1] hv: Update MAINTAINERS
From: Sasha Levin @ 2011-12-02 14:38 UTC (permalink / raw)
To: Jiri Kosina
Cc: K. Y. Srinivasan, gregkh, linux-kernel, devel, virtualization,
ohering, joe, dmitry.torokhov, Haiyang Zhang
In-Reply-To: <alpine.LNX.2.00.1112021531230.18207@pobox.suse.cz>
On Fri, 2011-12-02 at 15:31 +0100, Jiri Kosina wrote:
> On Thu, 1 Dec 2011, K. Y. Srinivasan wrote:
>
> > Update the MAINTAINERS file to reflect the current state
> > of the Hyper-V drivers.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> > MAINTAINERS | 16 ++++++++++------
> > 1 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3523ab0..809cad8 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3197,6 +3197,16 @@ M: William Irwin <wli@holomorphy.com>
> > S: Maintained
> > F: fs/hugetlbfs/
> >
> > +Hyper-V CORE AND DRIVERS
> > +M: K. Y. Srinivasan <kys@microsoft.com>
> > +M: Haiyang Zhang <haiyangz@microsoft.com>
> > +L: devel@linuxdriverproject.org
> > +S: Maintained
> > +F: drivers/hv/
> > +F: drivers/hid/hid-hyperv.c
> > +F: drivers/net/hyperv/
> > +F: drivers/staging/hv/
> > +
>
> I will be taking this through trivial tree. Thanks,
It should probably be 'S: Supported' though, right?
--
Sasha.
^ permalink raw reply
* Re: [PATCH 1/1] hv: Update MAINTAINERS
From: Jiri Kosina @ 2011-12-02 14:31 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, ohering, joe,
dmitry.torokhov, Haiyang Zhang
In-Reply-To: <1322778690-17381-1-git-send-email-kys@microsoft.com>
On Thu, 1 Dec 2011, K. Y. Srinivasan wrote:
> Update the MAINTAINERS file to reflect the current state
> of the Hyper-V drivers.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> MAINTAINERS | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3523ab0..809cad8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3197,6 +3197,16 @@ M: William Irwin <wli@holomorphy.com>
> S: Maintained
> F: fs/hugetlbfs/
>
> +Hyper-V CORE AND DRIVERS
> +M: K. Y. Srinivasan <kys@microsoft.com>
> +M: Haiyang Zhang <haiyangz@microsoft.com>
> +L: devel@linuxdriverproject.org
> +S: Maintained
> +F: drivers/hv/
> +F: drivers/hid/hid-hyperv.c
> +F: drivers/net/hyperv/
> +F: drivers/staging/hv/
> +
I will be taking this through trivial tree. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
From: Raghavendra K T @ 2011-12-02 12:29 UTC (permalink / raw)
To: Avi Kivity
Cc: Jeremy Fitzhardinge, x86, Peter Zijlstra, Virtualization,
H. Peter Anvin, Stefano Stabellini, Xen, Dave Jiang, KVM,
Raghavendra K T, Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
Srivatsa Vaddagiri, Jeremy Fitzhardinge, Sasha Levin, Sedat Dilek,
Thomas Gleixner, Yinghai Lu, Greg Kroah-Hartman, LKML,
Dave Hansen, Suzuki
In-Reply-To: <4ED7DA85.5080504@linux.vnet.ibm.com>
On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>>> + struct kvm_mp_state mp_state;
>>> +
>>> + mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>>> + if (vcpu) {
>>> + vcpu->kicked = 1;
>>> + /* Ensure kicked is always set before wakeup */
>>> + barrier();
>>> + }
>>> + kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
>>
>> This must only be called from the vcpu thread.
>
> Hmm. Okay. 'll check this.
>
Yes true. kvm_arch_vcpu_ioctl_set_mpstate itself is redundant, and will
remove this.
^ permalink raw reply
* Re: [PATCH] Add virtio-scsi to the virtio spec
From: Rusty Russell @ 2011-12-02 0:51 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Michael S. Tsirkin, LKML, Stefan Hajnoczi, virtualization
In-Reply-To: <4ED74102.6040207@redhat.com>
On Thu, 01 Dec 2011 09:55:30 +0100, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 12/01/2011 04:14 AM, Rusty Russell wrote:
> > I'd prefer to see the spec only cover things
> > which are implemented and tested, otherwise the risk of a flaw in the
> > spec is really high in my experience.
>
> In general I agree, and I did that for virtio-specific things such as
> the eventq and the configuration space. This is also why I don't want
> to add untested controlq requests that people suggested.
>
> However, there's tension between this and providing a complete SCSI
> transport. SCSI is roughly defined as a set of RPC interfaces ("Send
> command", "Abort task", etc.) and transports provide the RPC protocol.
> The SCSI command set changes relatively often, but the RPC interfaces
> are pretty stable. This stability limits the risk, and having a mapping
> for all interfaces also makes future changes less likely.
OK, I expect that someone reading the spec will be SCSI-familiar more
than virtio-familiar, so it's more important that they be comfortable,
than that I be comfortable.
Thanks!
Rusty.
^ permalink raw reply
* Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
From: Rusty Russell @ 2011-12-02 0:46 UTC (permalink / raw)
To: Michael S. Tsirkin, Sasha Levin
Cc: markmc, virtualization, Avi Kivity, kvm, linux-kernel
In-Reply-To: <20111201102640.GB8822@redhat.com>
On Thu, 1 Dec 2011 12:26:42 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> > On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > > We'll presumably need some logic to increment is back,
> > > to account for random workload changes.
> > > Something like slow start?
> >
> > We can increment it each time the queue was less than 10% full, it
> > should act like slow start, no?
>
> No, we really shouldn't get an empty ring as long as things behave
> well. What I meant is something like:
I was thinking of the network output case, but you're right. We need to
distinguish between usually full (eg. virtio-net input) and usually
empty (eg. virtio-net output).
The signal for "we to pack more into the ring" is different. We could
use some hacky heuristic like "out == 0" but I'd rather make it explicit
when we set up the virtqueue.
Our other alternative, moving the logic to the driver, is worse.
As to fading the effect over time, that's harder. We have to deplete
the ring quite a few times before it turns into always-indirect. We
could back off every time the ring is totally idle, but that may hurt
bursty traffic. Let's try simple first?
Thanks,
Rusty.
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Rusty Russell @ 2011-12-02 0:26 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-arm-kernel, linux-kernel, kvm, virtualization
In-Reply-To: <20111201081236.GB5479@redhat.com>
On Thu, 1 Dec 2011 10:12:37 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Dec 01, 2011 at 12:58:59PM +1030, Rusty Russell wrote:
> > On Thu, 1 Dec 2011 01:13:07 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > For x86, stores into memory are ordered. So I think that yes, smp_XXX
> > > can be selected at compile time.
> > >
> > > So let's forget the virtio strangeness for a minute,
> >
> > Hmm, we got away with light barriers because we knew we were not
> > *really* talking to a device. But now with virtio-mmio, turns out we
> > are :)
>
> You think virtio-mmio this issue too? It's reported on remoteproc...
I think any non-virtual, non-PCI device has to worry about it. Perhaps
all virtio-mmio are virtual (at this point).
I'm tempted to say we want permission from the device to do relaxed
barriers (so I don't have to worry about it!)
> > I'm really tempted to revert d57ed95 for 3.2, and we can revisit this
> > optimization later if it proves worthwhile.
>
> Generally it does seem the best we can do for 3.2.
>
> Given it's rc3, I'd be a bit wary of introducing regressions - I'll try
> to find some real setups (as in - not my laptop) to run some benchmarks
> on, to verify there's no major problem.
> I hope I can report on this in about a week from now - want to hold onto this meanwhile?
Yep, no huge hurry. Thanks!
Cheers,
Rusty.
^ permalink raw reply
* [PATCH 1/1] hv: Update MAINTAINERS
From: K. Y. Srinivasan @ 2011-12-01 22:31 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, ohering, joe,
dmitry.torokhov, jkosina
Cc: K. Y. Srinivasan, Haiyang Zhang
Update the MAINTAINERS file to reflect the current state
of the Hyper-V drivers.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
MAINTAINERS | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3523ab0..809cad8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3197,6 +3197,16 @@ M: William Irwin <wli@holomorphy.com>
S: Maintained
F: fs/hugetlbfs/
+Hyper-V CORE AND DRIVERS
+M: K. Y. Srinivasan <kys@microsoft.com>
+M: Haiyang Zhang <haiyangz@microsoft.com>
+L: devel@linuxdriverproject.org
+S: Maintained
+F: drivers/hv/
+F: drivers/hid/hid-hyperv.c
+F: drivers/net/hyperv/
+F: drivers/staging/hv/
+
I2C/SMBUS STUB DRIVER
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
L: linux-i2c@vger.kernel.org
@@ -6322,12 +6332,6 @@ M: David Täht <d@teklibre.com>
S: Odd Fixes
F: drivers/staging/frontier/
-STAGING - HYPER-V (MICROSOFT)
-M: Hank Janssen <hjanssen@microsoft.com>
-M: Haiyang Zhang <haiyangz@microsoft.com>
-S: Odd Fixes
-F: drivers/staging/hv/
-
STAGING - INDUSTRIAL IO
M: Jonathan Cameron <jic23@cam.ac.uk>
L: linux-iio@vger.kernel.org
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/1] hv: Update MAINTAINERS
From: Greg KH @ 2011-12-01 22:04 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: linux-kernel, devel, virtualization, ohering, joe,
dmitry.torokhov, jkosina, Haiyang Zhang
In-Reply-To: <1322776486-17077-1-git-send-email-kys@microsoft.com>
On Thu, Dec 01, 2011 at 01:54:46PM -0800, K. Y. Srinivasan wrote:
> Update the MAINTAINERS file to reflect the current state
> of the Hyper-V drivers.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> MAINTAINERS | 25 +++++++++++++++++++++++--
> 1 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3523ab0..db6cee2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3197,6 +3197,27 @@ M: William Irwin <wli@holomorphy.com>
> S: Maintained
> F: fs/hugetlbfs/
>
> +Hyper-V CORE DRIVERS
> +M: K. Y. Srinivasan <kys@microsoft.com>
> +M: Haiyang Zhang <haiyangz@microsoft.com>
> +L: devel@linuxdriverproject.org
> +S: Maintained
> +F: drivers/hv/
> +
> +Hyper-V MOUSE DRIVER
> +M: K. Y. Srinivasan <kys@microsoft.com>
> +M: Haiyang Zhang <haiyangz@microsoft.com>
> +L: devel@linuxdriverproject.org
> +S: Maintained
> +F: drivers/hid/hid-hyperv.c
> +
> +Hyper-V NETWORK DRIVER
> +M: K. Y. Srinivasan <kys@microsoft.com>
> +M: Haiyang Zhang <haiyangz@microsoft.com>
> +L: devel@linuxdriverproject.org
> +S: Maintained
> +F: drivers/net/hyperv/
This whole patch could all be consolidated into one entry, that also
fixes the name of the subsystem to follow the rest of the file format:
HYPER-V CORE AND DRIVERS
M: K. Y. Srinivasan <kys@microsoft.com>
M: Haiyang Zhang <haiyangz@microsoft.com>
L: devel@linuxdriverproject.org
S: Maintained
F: drivers/hv/
F: drivers/hid/hid-hyperv.c
F: drivers/net/hyperv/
F: drivers/staging/hv/
Care to redo this?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 1/1] hv: Update MAINTAINERS
From: K. Y. Srinivasan @ 2011-12-01 21:54 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, ohering, joe,
dmitry.torokhov, jkosina
Cc: K. Y. Srinivasan, Haiyang Zhang
Update the MAINTAINERS file to reflect the current state
of the Hyper-V drivers.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
MAINTAINERS | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3523ab0..db6cee2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3197,6 +3197,27 @@ M: William Irwin <wli@holomorphy.com>
S: Maintained
F: fs/hugetlbfs/
+Hyper-V CORE DRIVERS
+M: K. Y. Srinivasan <kys@microsoft.com>
+M: Haiyang Zhang <haiyangz@microsoft.com>
+L: devel@linuxdriverproject.org
+S: Maintained
+F: drivers/hv/
+
+Hyper-V MOUSE DRIVER
+M: K. Y. Srinivasan <kys@microsoft.com>
+M: Haiyang Zhang <haiyangz@microsoft.com>
+L: devel@linuxdriverproject.org
+S: Maintained
+F: drivers/hid/hid-hyperv.c
+
+Hyper-V NETWORK DRIVER
+M: K. Y. Srinivasan <kys@microsoft.com>
+M: Haiyang Zhang <haiyangz@microsoft.com>
+L: devel@linuxdriverproject.org
+S: Maintained
+F: drivers/net/hyperv/
+
I2C/SMBUS STUB DRIVER
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
L: linux-i2c@vger.kernel.org
@@ -6323,9 +6344,9 @@ S: Odd Fixes
F: drivers/staging/frontier/
STAGING - HYPER-V (MICROSOFT)
-M: Hank Janssen <hjanssen@microsoft.com>
+M: K. Y. Srinivasan <kys@microsoft.com>
M: Haiyang Zhang <haiyangz@microsoft.com>
-S: Odd Fixes
+S: Maintained
F: drivers/staging/hv/
STAGING - INDUSTRIAL IO
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH 4/5] Staging: hv: storvsc: Fix a bug in copy_from_bounce_buffer()
From: KY Srinivasan @ 2011-12-01 21:13 UTC (permalink / raw)
To: Dan Carpenter
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, James.Bottomley@HansenPartnership.com,
hch@infradead.org, linux-scsi@vger.kernel.org, Haiyang Zhang
In-Reply-To: <20111201211147.GL20466@mwanda>
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Thursday, December 01, 2011 4:12 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; ohering@suse.com;
> James.Bottomley@HansenPartnership.com; hch@infradead.org; linux-
> scsi@vger.kernel.org; Haiyang Zhang
> Subject: Re: [PATCH 4/5] Staging: hv: storvsc: Fix a bug in
> copy_from_bounce_buffer()
>
> On Thu, Dec 01, 2011 at 09:07:46PM +0000, KY Srinivasan wrote:
> > Sorry Dan. I put in some comments in the code describing the bug. Perhaps I
> > should have copied that in the changelog as well.
>
> Yes. That's the entire point of the changelog, in fact. Could you
> fix it and resend?
I could do that, but Greg has already checked in this patch.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 4/5] Staging: hv: storvsc: Fix a bug in copy_from_bounce_buffer()
From: Dan Carpenter @ 2011-12-01 21:11 UTC (permalink / raw)
To: KY Srinivasan
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, James.Bottomley@HansenPartnership.com,
hch@infradead.org, linux-scsi@vger.kernel.org, Haiyang Zhang
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481AA7B4EF@TK5EX14MBXC126.redmond.corp.microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
On Thu, Dec 01, 2011 at 09:07:46PM +0000, KY Srinivasan wrote:
> Sorry Dan. I put in some comments in the code describing the bug. Perhaps I
> should have copied that in the changelog as well.
Yes. That's the entire point of the changelog, in fact. Could you
fix it and resend?
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH 4/5] Staging: hv: storvsc: Fix a bug in copy_from_bounce_buffer()
From: KY Srinivasan @ 2011-12-01 21:07 UTC (permalink / raw)
To: Dan Carpenter
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, James.Bottomley@HansenPartnership.com,
hch@infradead.org, linux-scsi@vger.kernel.org, Haiyang Zhang
In-Reply-To: <20111201210304.GY3195@mwanda>
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Thursday, December 01, 2011 4:03 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; ohering@suse.com;
> James.Bottomley@HansenPartnership.com; hch@infradead.org; linux-
> scsi@vger.kernel.org; Haiyang Zhang
> Subject: Re: [PATCH 4/5] Staging: hv: storvsc: Fix a bug in
> copy_from_bounce_buffer()
>
> On Thu, Dec 01, 2011 at 04:59:19AM -0800, K. Y. Srinivasan wrote:
> > Fix a bug in copy_from_bounce_buffer().
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
>
> Seriously? ...
>
> This is a crap changelog. What did the bug do?
Sorry Dan. I put in some comments in the code describing the bug. Perhaps I
should have copied that in the changelog as well.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 4/5] Staging: hv: storvsc: Fix a bug in copy_from_bounce_buffer()
From: Dan Carpenter @ 2011-12-01 21:03 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, ohering,
James.Bottomley, hch, linux-scsi, Haiyang Zhang
In-Reply-To: <1322744360-13067-4-git-send-email-kys@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
On Thu, Dec 01, 2011 at 04:59:19AM -0800, K. Y. Srinivasan wrote:
> Fix a bug in copy_from_bounce_buffer().
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Seriously? ...
This is a crap changelog. What did the bug do?
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: mousevsc: Properly add the hid device
From: Jiri Kosina @ 2011-12-01 19:55 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, ohering, joe,
dmitry.torokhov, Haiyang Zhang
In-Reply-To: <1322671943-6788-1-git-send-email-kys@microsoft.com>
On Wed, 30 Nov 2011, K. Y. Srinivasan wrote:
> We need to properly add the hid device to correctly initialize the
> sysfs state. While this patch is against the staging tree; Jiri,
> please pick up this patch as you merge the Hyper-V mouse driver.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reported-by: Fuzhou Chen <fuzhouch@microsoft.com>
> ---
> drivers/staging/hv/hv_mouse.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/hv/hv_mouse.c b/drivers/staging/hv/hv_mouse.c
> index a28c549..66da8e3 100644
> --- a/drivers/staging/hv/hv_mouse.c
> +++ b/drivers/staging/hv/hv_mouse.c
> @@ -519,6 +519,10 @@ static int mousevsc_probe(struct hv_device *device,
>
> sprintf(hid_dev->name, "%s", "Microsoft Vmbus HID-compliant Mouse");
>
> + ret = hid_add_device(hid_dev);
> + if (ret)
> + goto probe_err1;
> +
> ret = hid_parse_report(hid_dev, input_dev->report_desc,
> input_dev->report_desc_size);
>
I have refreshed the patch to apply to drivers/hid/hid-hyperv.c driver and
applied. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
From: Raghavendra K T @ 2011-12-01 19:50 UTC (permalink / raw)
To: Avi Kivity
Cc: Jeremy Fitzhardinge, x86, Peter Zijlstra, Virtualization,
H. Peter Anvin, Stefano Stabellini, Xen, Dave Jiang, KVM,
Raghavendra K T, Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
Srivatsa Vaddagiri, Jeremy Fitzhardinge, Sasha Levin, Sedat Dilek,
Thomas Gleixner, Yinghai Lu, Greg Kroah-Hartman, LKML,
Dave Hansen, Suzuki
In-Reply-To: <4ED760F1.6080804@redhat.com>
[ CCing Jeremy's new email ID ]
Hi Avi,
Thanks for review and inputs.
On 12/01/2011 04:41 PM, Avi Kivity wrote:
> On 11/30/2011 10:59 AM, Raghavendra K T wrote:
>
> The hypercall needs to be documented in
> Documentation/virtual/kvm/hypercalls.txt.
>
Yes, Sure 'll document. hypercalls.txt is a new file right?. also I
have to document APIs in Documentation/virtual/kvm/api.txt.
> Have you tested it on AMD machines? There are some differences in the
> hypercall infrastructure there.
Yes. 'll test on AMD machine and update on that.
>
>> /* This indicates that the new set of kvmclock msrs
>> * are available. The use of 0x11 and 0x12 is deprecated
>> */
>> #define KVM_FEATURE_CLOCKSOURCE2 3
>> #define KVM_FEATURE_ASYNC_PF 4
>> #define KVM_FEATURE_STEAL_TIME 5
>> +#define KVM_FEATURE_KICK_VCPU 6
>
> Documentation/virtual/kvm/cpuid.txt.
Yes. 'll do that.
>
>>
>> /* The last 8 bits are used to indicate how to interpret the flags field
>> * in pvclock structure. If no bits are set, all flags are ignored.
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index c38efd7..6e1c8b4 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>> case KVM_CAP_XSAVE:
>> case KVM_CAP_ASYNC_PF:
>> case KVM_CAP_GET_TSC_KHZ:
>> + case KVM_CAP_KICK_VCPU:
>
> This is redundant with the feature bit? In general, KVM_CAP is for the
> host API, while KVM_FEATURE is for the guest API.
>
No its not. I have to check the flow again. I understood that this
completes the guest querying, that checks for KVM_FEATURE availability.
Did I miss something? I need a little deep dive though.
>>
>> +/*
>> + * kvm_pv_kick_cpu_op: Kick a vcpu.
>> + *
>> + * @cpu - vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>> +{
>> + struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>
> There is no guarantee that guest cpu numbers match host vcpu numbers.
> Use APIC IDs, and kvm_apic_match_dest().
Okay. I have to dig more on this.
>
>> + struct kvm_mp_state mp_state;
>> +
>> + mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>> + if (vcpu) {
>> + vcpu->kicked = 1;
>> + /* Ensure kicked is always set before wakeup */
>> + barrier();
>> + }
>> + kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
>
> This must only be called from the vcpu thread.
Hmm. Okay. 'll check this.
>
>> + kvm_vcpu_kick(vcpu);
>> +}
>> +
>>
>> struct kvm_vcpu_arch arch;
>> +
>> + /*
>> + * blocked vcpu wakes up by checking this flag set by unlocker.
>> + */
>> + int kicked;
>>
>
> Write only variable.
Yes 'll remove comments.
>
> An alternative approach is to use an MSR protocol like x2apic ICR.
>
'll explore on this too.
^ permalink raw reply
* [PATCH 1/1] drivers: hv: Don't OOPS when you cannot init vmbus
From: K. Y. Srinivasan @ 2011-12-01 17:59 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, ohering
Cc: K. Y. Srinivasan, Sasha Levin
The hv vmbus driver was causing an OOPS since it was trying to register drivers
on top of the bus even if initialization of the bus has failed for some
reason (such as the odd chance someone would run a hv enabled kernel in a
non-hv environment).
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/hv/vmbus_drv.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 0c048dd..d3b0b4f 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -62,6 +62,14 @@ struct hv_device_info {
struct hv_dev_port_info outbound;
};
+static int vmbus_exists(void)
+{
+ if (hv_acpi_dev == NULL)
+ return -ENODEV;
+
+ return 0;
+}
+
static void get_channel_info(struct hv_device *device,
struct hv_device_info *info)
@@ -590,6 +598,10 @@ int __vmbus_driver_register(struct hv_driver *hv_driver, struct module *owner, c
pr_info("registering driver %s\n", hv_driver->name);
+ ret = vmbus_exists();
+ if (ret < 0)
+ return ret;
+
hv_driver->driver.name = hv_driver->name;
hv_driver->driver.owner = owner;
hv_driver->driver.mod_name = mod_name;
@@ -614,6 +626,9 @@ void vmbus_driver_unregister(struct hv_driver *hv_driver)
{
pr_info("unregistering driver %s\n", hv_driver->name);
+ if (!vmbus_exists())
+ return;
+
driver_unregister(&hv_driver->driver);
}
@@ -776,6 +791,7 @@ static int __init hv_acpi_init(void)
cleanup:
acpi_bus_unregister_driver(&vmbus_acpi_driver);
+ hv_acpi_dev = NULL;
return ret;
}
--
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