<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/virtio, branch v2.6.34-rc1</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>virtio: set pci bus master enable bit</title>
<updated>2010-03-02T11:41:14+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2009-11-29T15:52:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bc505f373979692d51a86d40925f77a8b09d17b9'/>
<id>bc505f373979692d51a86d40925f77a8b09d17b9</id>
<content type='text'>
As all virtio devices perform DMA, we
must enable bus mastering for them to be
spec compliant.

This patch fixes hotplug of virtio devices
with Linux guests and qemu 0.11-0.12.

Tested-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As all virtio devices perform DMA, we
must enable bus mastering for them to be
spec compliant.

This patch fixes hotplug of virtio devices
with Linux guests and qemu 0.11-0.12.

Tested-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: fix out of range array access</title>
<updated>2010-02-28T18:39:11+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2010-02-25T17:08:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3119815912a220bdac943dfbdfee640414c0c611'/>
<id>3119815912a220bdac943dfbdfee640414c0c611</id>
<content type='text'>
I have observed the following error on virtio-net module unload:

------------[ cut here ]------------
WARNING: at kernel/irq/manage.c:858 __free_irq+0xa0/0x14c()
Hardware name: Bochs
Trying to free already-free IRQ 0
Modules linked in: virtio_net(-) virtio_blk virtio_pci virtio_ring
virtio af_packet e1000 shpchp aacraid uhci_hcd ohci_hcd ehci_hcd [last
unloaded: scsi_wait_scan]
Pid: 1957, comm: rmmod Not tainted 2.6.33-rc8-vhost #24
Call Trace:
 [&lt;ffffffff8103e195&gt;] warn_slowpath_common+0x7c/0x94
 [&lt;ffffffff8103e204&gt;] warn_slowpath_fmt+0x41/0x43
 [&lt;ffffffff810a7a36&gt;] ? __free_pages+0x5a/0x70
 [&lt;ffffffff8107cc00&gt;] __free_irq+0xa0/0x14c
 [&lt;ffffffff8107cceb&gt;] free_irq+0x3f/0x65
 [&lt;ffffffffa0081424&gt;] vp_del_vqs+0x81/0xb1 [virtio_pci]
 [&lt;ffffffffa0091d29&gt;] virtnet_remove+0xda/0x10b [virtio_net]
 [&lt;ffffffffa0075200&gt;] virtio_dev_remove+0x22/0x4a [virtio]
 [&lt;ffffffff812709ee&gt;] __device_release_driver+0x66/0xac
 [&lt;ffffffff81270ab7&gt;] driver_detach+0x83/0xa9
 [&lt;ffffffff8126fc66&gt;] bus_remove_driver+0x91/0xb4
 [&lt;ffffffff81270fcf&gt;] driver_unregister+0x6c/0x74
 [&lt;ffffffffa0075418&gt;] unregister_virtio_driver+0xe/0x10 [virtio]
 [&lt;ffffffffa0091c4d&gt;] fini+0x15/0x17 [virtio_net]
 [&lt;ffffffff8106997b&gt;] sys_delete_module+0x1c3/0x230
 [&lt;ffffffff81007465&gt;] ? old_ich_force_enable_hpet+0x117/0x164
 [&lt;ffffffff813bb720&gt;] ? do_page_fault+0x29c/0x2cc
 [&lt;ffffffff81028e58&gt;] sysenter_dispatch+0x7/0x27
---[ end trace 15e88e4c576cc62b ]---

The bug is in virtio-pci: we use msix_vector as array index to get irq
entry, but some vqs do not have a dedicated vector so this causes an out
of bounds access.  By chance, we seem to often get 0 value, which
results in this error.

Fix by verifying that vector is legal before using it as index.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Acked-by: Anthony Liguori &lt;aliguori@us.ibm.com&gt;
Acked-by: Shirley Ma &lt;xma@us.ibm.com&gt;
Acked-by: Amit Shah &lt;amit.shah@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I have observed the following error on virtio-net module unload:

------------[ cut here ]------------
WARNING: at kernel/irq/manage.c:858 __free_irq+0xa0/0x14c()
Hardware name: Bochs
Trying to free already-free IRQ 0
Modules linked in: virtio_net(-) virtio_blk virtio_pci virtio_ring
virtio af_packet e1000 shpchp aacraid uhci_hcd ohci_hcd ehci_hcd [last
unloaded: scsi_wait_scan]
Pid: 1957, comm: rmmod Not tainted 2.6.33-rc8-vhost #24
Call Trace:
 [&lt;ffffffff8103e195&gt;] warn_slowpath_common+0x7c/0x94
 [&lt;ffffffff8103e204&gt;] warn_slowpath_fmt+0x41/0x43
 [&lt;ffffffff810a7a36&gt;] ? __free_pages+0x5a/0x70
 [&lt;ffffffff8107cc00&gt;] __free_irq+0xa0/0x14c
 [&lt;ffffffff8107cceb&gt;] free_irq+0x3f/0x65
 [&lt;ffffffffa0081424&gt;] vp_del_vqs+0x81/0xb1 [virtio_pci]
 [&lt;ffffffffa0091d29&gt;] virtnet_remove+0xda/0x10b [virtio_net]
 [&lt;ffffffffa0075200&gt;] virtio_dev_remove+0x22/0x4a [virtio]
 [&lt;ffffffff812709ee&gt;] __device_release_driver+0x66/0xac
 [&lt;ffffffff81270ab7&gt;] driver_detach+0x83/0xa9
 [&lt;ffffffff8126fc66&gt;] bus_remove_driver+0x91/0xb4
 [&lt;ffffffff81270fcf&gt;] driver_unregister+0x6c/0x74
 [&lt;ffffffffa0075418&gt;] unregister_virtio_driver+0xe/0x10 [virtio]
 [&lt;ffffffffa0091c4d&gt;] fini+0x15/0x17 [virtio_net]
 [&lt;ffffffff8106997b&gt;] sys_delete_module+0x1c3/0x230
 [&lt;ffffffff81007465&gt;] ? old_ich_force_enable_hpet+0x117/0x164
 [&lt;ffffffff813bb720&gt;] ? do_page_fault+0x29c/0x2cc
 [&lt;ffffffff81028e58&gt;] sysenter_dispatch+0x7/0x27
---[ end trace 15e88e4c576cc62b ]---

The bug is in virtio-pci: we use msix_vector as array index to get irq
entry, but some vqs do not have a dedicated vector so this causes an out
of bounds access.  By chance, we seem to often get 0 value, which
results in this error.

Fix by verifying that vector is legal before using it as index.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Acked-by: Anthony Liguori &lt;aliguori@us.ibm.com&gt;
Acked-by: Shirley Ma &lt;xma@us.ibm.com&gt;
Acked-by: Amit Shah &lt;amit.shah@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: Initialize vq-&gt;data entries to NULL</title>
<updated>2010-02-24T03:52:29+00:00</updated>
<author>
<name>Amit Shah</name>
<email>amit.shah@redhat.com</email>
</author>
<published>2010-02-12T05:02:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3b8706240ee6084ccb46e53cd3a554356b7eeec8'/>
<id>3b8706240ee6084ccb46e53cd3a554356b7eeec8</id>
<content type='text'>
vq operations depend on vq-&gt;data[i] being NULL to figure out if the vq
entry is in use (since the previous patch).

We have to initialize them to NULL to ensure we don't work with junk
data and trigger false BUG_ONs.

Signed-off-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Shirley Ma &lt;xma@us.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
vq operations depend on vq-&gt;data[i] being NULL to figure out if the vq
entry is in use (since the previous patch).

We have to initialize them to NULL to ensure we don't work with junk
data and trigger false BUG_ONs.

Signed-off-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Shirley Ma &lt;xma@us.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: Add ability to detach unused buffers from vrings</title>
<updated>2010-02-24T03:52:27+00:00</updated>
<author>
<name>Shirley Ma</name>
<email>mashirle@us.ibm.com</email>
</author>
<published>2010-01-18T13:45:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c021eac4148c16bf53baa0dd14e8ebee6f39dab5'/>
<id>c021eac4148c16bf53baa0dd14e8ebee6f39dab5</id>
<content type='text'>
There's currently no way for a virtio driver to ask for unused
buffers, so it has to keep a list itself to reclaim them at shutdown.
This is redundant, since virtio_ring stores that information.  So
add a new hook to do this.

Signed-off-by: Shirley Ma &lt;xma@us.ibm.com&gt;
Signed-off-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There's currently no way for a virtio driver to ask for unused
buffers, so it has to keep a list itself to reclaim them at shutdown.
This is redundant, since virtio_ring stores that information.  So
add a new hook to do this.

Signed-off-by: Shirley Ma &lt;xma@us.ibm.com&gt;
Signed-off-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: use smp_XX barriers on SMP</title>
<updated>2010-02-24T03:52:25+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2010-01-27T22:42:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d57ed95da483418e8b0433da693c9168dd0a2df6'/>
<id>d57ed95da483418e8b0433da693c9168dd0a2df6</id>
<content type='text'>
virtio is communicating with a virtual "device" that actually runs on
another host processor. Thus SMP barriers can be used to control
memory access ordering.

Where possible, we should use SMP barriers which are more lightweight than
mandatory barriers, because mandatory barriers also control MMIO effects on
accesses through relaxed memory I/O windows (which virtio does not use)
(compare specifically smp_rmb and rmb on x86_64).

We can't just use smp_mb and friends though, because
we must force memory ordering even if guest is UP since host could be
running on another CPU, but SMP barriers are defined to barrier() in
that configuration. So, for UP fall back to mandatory barriers instead.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
virtio is communicating with a virtual "device" that actually runs on
another host processor. Thus SMP barriers can be used to control
memory access ordering.

Where possible, we should use SMP barriers which are more lightweight than
mandatory barriers, because mandatory barriers also control MMIO effects on
accesses through relaxed memory I/O windows (which virtio does not use)
(compare specifically smp_rmb and rmb on x86_64).

We can't just use smp_mb and friends though, because
we must force memory ordering even if guest is UP since host could be
running on another CPU, but SMP barriers are defined to barrier() in
that configuration. So, for UP fall back to mandatory barriers instead.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: remove bogus barriers from DEBUG version of virtio_ring.c</title>
<updated>2010-02-24T03:52:24+00:00</updated>
<author>
<name>Rusty Russell</name>
<email>rusty@rustcorp.com.au</email>
</author>
<published>2010-02-24T20:22:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=97a545ab6ce922a0f868d192718a48a0091ebc5e'/>
<id>97a545ab6ce922a0f868d192718a48a0091ebc5e</id>
<content type='text'>
With DEBUG defined, we add an -&gt;in_use flag to detect if the caller
invokes two virtio methods in parallel.  The barriers attempt to ensure
timely update of the -&gt;in_use flag.

But they're voodoo: if we need these barriers it implies that the
calling code doesn't have sufficient synchronization to ensure the
code paths aren't invoked at the same time anyway, and we want to
detect it.

Also, adding barriers changes timing, so turning on debug has more
chance of hiding real problems.

Thanks to MST for drawing my attention to this code...

CC: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With DEBUG defined, we add an -&gt;in_use flag to detect if the caller
invokes two virtio methods in parallel.  The barriers attempt to ensure
timely update of the -&gt;in_use flag.

But they're voodoo: if we need these barriers it implies that the
calling code doesn't have sufficient synchronization to ensure the
code paths aren't invoked at the same time anyway, and we want to
detect it.

Also, adding barriers changes timing, so turning on debug has more
chance of hiding real problems.

Thanks to MST for drawing my attention to this code...

CC: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: fix balloon without VIRTIO_BALLOON_F_STATS_VQ</title>
<updated>2010-02-24T03:52:17+00:00</updated>
<author>
<name>Rusty Russell</name>
<email>rusty@rustcorp.com.au</email>
</author>
<published>2010-02-24T20:22:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=169c246a30808588436794e96a97c61a01af9bed'/>
<id>169c246a30808588436794e96a97c61a01af9bed</id>
<content type='text'>
When running under qemu-kvm-0.11.0:

	BUG: unable to handle kernel paging request at 56e58955
	...
	Process vballoon (pid: 1297, ti=c7976000 task=c70a6ca0 task.ti=c7
	...
	Call Trace:
	 [&lt;c88253a3&gt;] ? balloon+0x1b3/0x440 [virtio_balloon]
	 [&lt;c041c2d7&gt;] ? schedule+0x327/0x9d0
	 [&lt;c88251f0&gt;] ? balloon+0x0/0x440 [virtio_balloon]
	 [&lt;c014a2d4&gt;] ? kthread+0x74/0x80
	 [&lt;c014a260&gt;] ? kthread+0x0/0x80
	 [&lt;c0103b36&gt;] ? kernel_thread_helper+0x6/0x30

need_stats_update should be zero-initialized.

Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Acked-by: Adam Litke &lt;agl@us.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When running under qemu-kvm-0.11.0:

	BUG: unable to handle kernel paging request at 56e58955
	...
	Process vballoon (pid: 1297, ti=c7976000 task=c70a6ca0 task.ti=c7
	...
	Call Trace:
	 [&lt;c88253a3&gt;] ? balloon+0x1b3/0x440 [virtio_balloon]
	 [&lt;c041c2d7&gt;] ? schedule+0x327/0x9d0
	 [&lt;c88251f0&gt;] ? balloon+0x0/0x440 [virtio_balloon]
	 [&lt;c014a2d4&gt;] ? kthread+0x74/0x80
	 [&lt;c014a260&gt;] ? kthread+0x0/0x80
	 [&lt;c0103b36&gt;] ? kernel_thread_helper+0x6/0x30

need_stats_update should be zero-initialized.

Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Acked-by: Adam Litke &lt;agl@us.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: Fix scheduling while atomic in virtio_balloon stats</title>
<updated>2010-02-24T03:52:14+00:00</updated>
<author>
<name>Adam Litke</name>
<email>agl@us.ibm.com</email>
</author>
<published>2009-12-10T22:35:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1f34c71afe5115e77a49c4e67720a66e27053e54'/>
<id>1f34c71afe5115e77a49c4e67720a66e27053e54</id>
<content type='text'>
This is a fix for my earlier patch: "virtio: Add memory statistics reporting to
the balloon driver (V4)".

I discovered that all_vm_events() can sleep and therefore stats collection
cannot be done in interrupt context.  One solution is to handle the interrupt
by noting that stats need to be collected and waking the existing vballoon
kthread which will complete the work via stats_handle_request().  Rusty, is
this a saner way of doing business?

There is one issue that I would like a broader opinion on.  In stats_request, I
update vb-&gt;need_stats_update and then wake up the kthread.  The kthread uses
vb-&gt;need_stats_update as a condition variable.  Do I need a memory barrier
between the update and wake_up to ensure that my kthread sees the correct
value?  My testing suggests that it is not needed but I would like some
confirmation from the experts.

Signed-off-by: Adam Litke &lt;agl@us.ibm.com&gt;
To: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Anthony Liguori &lt;aliguori@linux.vnet.ibm.com&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a fix for my earlier patch: "virtio: Add memory statistics reporting to
the balloon driver (V4)".

I discovered that all_vm_events() can sleep and therefore stats collection
cannot be done in interrupt context.  One solution is to handle the interrupt
by noting that stats need to be collected and waking the existing vballoon
kthread which will complete the work via stats_handle_request().  Rusty, is
this a saner way of doing business?

There is one issue that I would like a broader opinion on.  In stats_request, I
update vb-&gt;need_stats_update and then wake up the kthread.  The kthread uses
vb-&gt;need_stats_update as a condition variable.  Do I need a memory barrier
between the update and wake_up to ensure that my kthread sees the correct
value?  My testing suggests that it is not needed but I would like some
confirmation from the experts.

Signed-off-by: Adam Litke &lt;agl@us.ibm.com&gt;
To: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Anthony Liguori &lt;aliguori@linux.vnet.ibm.com&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: Add memory statistics reporting to the balloon driver (V4)</title>
<updated>2010-02-24T03:52:08+00:00</updated>
<author>
<name>Adam Litke</name>
<email>agl@us.ibm.com</email>
</author>
<published>2009-11-30T16:14:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9564e138b1f6eb137f7149772438d3f3fb3277dd'/>
<id>9564e138b1f6eb137f7149772438d3f3fb3277dd</id>
<content type='text'>
Changes since V3:
 - Do not do endian conversions as they will be done in the host
 - Report stats that reference a quantity of memory in bytes
 - Minor coding style updates

Changes since V2:
 - Increase stat field size to 64 bits
 - Report all sizes in kb (not pages)
 - Drop anon_pages stat and fix endianness conversion

Changes since V1:
 - Use a virtqueue instead of the device config space

When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests.  The current method
employs a daemon running in each guest that communicates memory statistics to a
host daemon at a specified time interval.  The host daemon aggregates this
information and inflates and/or deflates balloons according to the level of
host memory pressure.  This approach is effective but overly complex since a
daemon must be installed inside each guest and coordinated to communicate with
the host.  A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them directly to the hypervisor.

This patch enables the guest-side support by adding stats collection and
reporting to the virtio balloon driver.

Signed-off-by: Adam Litke &lt;agl@us.ibm.com&gt;
Cc: Anthony Liguori &lt;anthony@codemonkey.ws&gt;
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt; (minor fixes)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Changes since V3:
 - Do not do endian conversions as they will be done in the host
 - Report stats that reference a quantity of memory in bytes
 - Minor coding style updates

Changes since V2:
 - Increase stat field size to 64 bits
 - Report all sizes in kb (not pages)
 - Drop anon_pages stat and fix endianness conversion

Changes since V1:
 - Use a virtqueue instead of the device config space

When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests.  The current method
employs a daemon running in each guest that communicates memory statistics to a
host daemon at a specified time interval.  The host daemon aggregates this
information and inflates and/or deflates balloons according to the level of
host memory pressure.  This approach is effective but overly complex since a
daemon must be installed inside each guest and coordinated to communicate with
the host.  A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them directly to the hypervisor.

This patch enables the guest-side support by adding stats collection and
reporting to the virtio balloon driver.

Signed-off-by: Adam Litke &lt;agl@us.ibm.com&gt;
Cc: Anthony Liguori &lt;anthony@codemonkey.ws&gt;
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt; (minor fixes)
</pre>
</div>
</content>
</entry>
<entry>
<title>Add __devexit_p around reference to virtio_pci_remove</title>
<updated>2010-02-24T03:52:04+00:00</updated>
<author>
<name>Jamie Lokier</name>
<email>jamie@shareable.org</email>
</author>
<published>2010-01-08T22:01:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1f08b833ddbdb1c8e81c4b1053c2ebb7b89cb437'/>
<id>1f08b833ddbdb1c8e81c4b1053c2ebb7b89cb437</id>
<content type='text'>
This is needed to compile with CONFIG_VIRTIO_PCI=y,
because virtio_pci_remove is marked __devexit.

Signed-off-by: Jamie Lokier &lt;jamie@shareable.org&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is needed to compile with CONFIG_VIRTIO_PCI=y,
because virtio_pci_remove is marked __devexit.

Signed-off-by: Jamie Lokier &lt;jamie@shareable.org&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</pre>
</div>
</content>
</entry>
</feed>
