| Message ID | 200905151448.49851.rusty@rustcorp.com.au |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
Rusty Russell wrote: > This patch may help diagnostics tho. > virtio: expose features in sysfs > > Each device negotiates feature bits; expose these in sysfs to help > diagnostics and debugging. okay, this is the info from my guest after applying the patch on its kernel. Or. [root@vm1 ~]# lspci | grep Ethernet 00:03.0 Ethernet controller: Qumranet, Inc. Virtio network device [root@vm1 ~]# cat /sys/class/net/eth0/features 0x20 [root@vm1 ~]# cat /sys/class/net/eth0/device/features 0000010000000000000000001000000000000000000000000000000000000000 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 19 May 2009 09:49:02 pm Or Gerlitz wrote: > okay, this is the info from my guest after applying the patch on its > kernel. ... > [root@vm1 ~]# cat /sys/class/net/eth0/device/features > 0000010000000000000000001000000000000000000000000000000000000000 Bit 5 = VIRTIO_NET_F_MAC (the host set the mac address) Bit 24 = VIRTIO_F_NOTIFY_ON_EMPTY You don't have any GSO or checksum offload here. Rusty. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Rusty Russell wrote: > Bit 5 = VIRTIO_NET_F_MAC (the host set the mac address) > Bit 24 = VIRTIO_F_NOTIFY_ON_EMPTY > You don't have any GSO or checksum offload here Just to make sure I'm in the correct direction - I need to cause these offloads to be advertised by the "lower" part of virtio (e.g the qemu virtio code) to the "upper" part (the quest kernel), correct? I understand that one of them is called front-end and the other back-end, but my intuitions don't go up to saying who's what... Or. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Or Gerlitz wrote: > Rusty Russell wrote: >> Bit 5 = VIRTIO_NET_F_MAC (the host set the mac address) >> Bit 24 = VIRTIO_F_NOTIFY_ON_EMPTY >> You don't have any GSO or checksum offload here > Just to make sure I'm in the correct direction - I need to cause these > offloads to be advertised by the "lower" part of virtio (e.g the qemu > virtio code) to the "upper" part (the quest kernel), correct? Yes. You can do that by running a recent kernel on the host, and compiling qemu with the headers from that kernel (you can generate them with make headers-install). > I understand that one of them is called front-end and the other > back-end, but my intuitions don't go up to saying who's what... > My preferred terms are driver (in the guest) and device (in the host), to mimic real hardware.
On Wed, 20 May 2009 03:50:23 pm Or Gerlitz wrote: > Rusty Russell wrote: > > Bit 5 = VIRTIO_NET_F_MAC (the host set the mac address) > > Bit 24 = VIRTIO_F_NOTIFY_ON_EMPTY > > You don't have any GSO or checksum offload here > > Just to make sure I'm in the correct direction - I need to cause these > offloads to be advertised by the "lower" part of virtio (e.g the qemu > virtio code) to the "upper" part (the quest kernel), correct? I > understand that one of them is called front-end and the other back-end, > but my intuitions don't go up to saying who's what... Yes, that nomenclature is a bit weird. I prefer "driver" (aka. guest, aka front-end) and "device" (aka. host, aka back-end). All virtio_net drivers offer some features (at least CSUM offload), and 2.6.26 and above will offer some serious GSO features. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c --- a/drivers/virtio/virtio.c +++ b/drivers/virtio/virtio.c @@ -31,11 +31,27 @@ static ssize_t modalias_show(struct devi return sprintf(buf, "virtio:d%08Xv%08X\n", dev->id.device, dev->id.vendor); } +static ssize_t features_show(struct device *_d, + struct device_attribute *attr, char *buf) +{ + struct virtio_device *dev = container_of(_d, struct virtio_device, dev); + unsigned int i; + ssize_t len = 0; + + /* We actually represent this as a bitstring, as it could be + * arbitrary length in future. */ + for (i = 0; i < ARRAY_SIZE(dev->features)*BITS_PER_LONG; i++) + len += sprintf(buf+len, "%c", + test_bit(i, dev->features) ? '1' : '0'); + len += sprintf(buf+len, "\n"); + return len; +} static struct device_attribute virtio_dev_attrs[] = { __ATTR_RO(device), __ATTR_RO(vendor), __ATTR_RO(status), __ATTR_RO(modalias), + __ATTR_RO(features), __ATTR_NULL };