* [RFC PATCH net-next v2] enable virtio_net to return bus_info in ethtool -i consistent with emulated NICs
From: Rick Jones @ 2011-11-15 0:17 UTC (permalink / raw)
To: netdev, rusty, mst, virtualization
From: Rick Jones <rick.jones2@hp.com>
Add a new .bus_name to virtio_config_ops then modify virtio_net to
call through to it in an ethtool .get_drvinfo routine to report
bus_info in ethtool -i output which is consistent with other
emulated NICs and the output of lspci.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
---
The changes to drivers/lguest/lguest_device.c, drivers/s390/kvm/kvm_virtio.c,
and drivers/virtio/virtio_mmio.c code inspected only, not compiled.
j-ubuntu-guest:~$ ethtool -i eth0
driver: virtio_net
version: 1.0.0
firmware-version:
bus-info: 0000:00:03.0
raj@raj-ubuntu-guest:~$ lspci | grep Ether
00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
drivers/lguest/lguest_device.c | 6 ++++++
drivers/net/virtio_net.c | 15 +++++++++++++++
drivers/s390/kvm/kvm_virtio.c | 6 ++++++
drivers/virtio/virtio_mmio.c | 6 ++++++
drivers/virtio/virtio_pci.c | 8 ++++++++
include/linux/virtio_config.h | 14 ++++++++++++++
6 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/drivers/lguest/lguest_device.c b/drivers/lguest/lguest_device.c
index 0dc30ff..595d731 100644
--- a/drivers/lguest/lguest_device.c
+++ b/drivers/lguest/lguest_device.c
@@ -381,6 +381,11 @@ error:
return PTR_ERR(vqs[i]);
}
+static const char *lg_bus_name(struct virtio_device *vdev)
+{
+ return "";
+}
+
/* The ops structure which hooks everything together. */
static struct virtio_config_ops lguest_config_ops = {
.get_features = lg_get_features,
@@ -392,6 +397,7 @@ static struct virtio_config_ops lguest_config_ops = {
.reset = lg_reset,
.find_vqs = lg_find_vqs,
.del_vqs = lg_del_vqs,
+ .bus_name = lg_bus_name,
};
/*
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 6ee8410..4dc9d84 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -39,6 +39,7 @@ module_param(gso, bool, 0444);
#define GOOD_COPY_LEN 128
#define VIRTNET_SEND_COMMAND_SG_MAX 2
+#define VIRTNET_DRIVER_VERSION "1.0.0"
struct virtnet_stats {
struct u64_stats_sync syncp;
@@ -889,7 +890,21 @@ static void virtnet_get_ringparam(struct net_device *dev,
}
+
+static void virtnet_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *info)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct virtio_device *vdev = vi->vdev;
+
+ strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
+ strlcpy(info->version, VIRTNET_DRIVER_VERSION, sizeof(info->version));
+ strlcpy(info->bus_info, virtio_bus_name(vdev), sizeof(info->bus_info));
+
+}
+
static const struct ethtool_ops virtnet_ethtool_ops = {
+ .get_drvinfo = virtnet_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_ringparam = virtnet_get_ringparam,
};
diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
index 94f49ff..8af868b 100644
--- a/drivers/s390/kvm/kvm_virtio.c
+++ b/drivers/s390/kvm/kvm_virtio.c
@@ -263,6 +263,11 @@ error:
return PTR_ERR(vqs[i]);
}
+static const char *kvm_bus_name(struct virtio_device *vdev)
+{
+ return "";
+}
+
/*
* The config ops structure as defined by virtio config
*/
@@ -276,6 +281,7 @@ static struct virtio_config_ops kvm_vq_configspace_ops = {
.reset = kvm_reset,
.find_vqs = kvm_find_vqs,
.del_vqs = kvm_del_vqs,
+ .bus_name = kvm_bus_name,
};
/*
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index acc5e43..2f57380 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -361,7 +361,12 @@ static int vm_find_vqs(struct virtio_device *vdev, unsigned nvqs,
return 0;
}
+static const char *vm_bus_name(struct virtio_device *vdev)
+{
+ struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
+ return vm_dev->pdev->name;
+}
static struct virtio_config_ops virtio_mmio_config_ops = {
.get = vm_get,
@@ -373,6 +378,7 @@ static struct virtio_config_ops virtio_mmio_config_ops = {
.del_vqs = vm_del_vqs,
.get_features = vm_get_features,
.finalize_features = vm_finalize_features,
+ .bus_name = vm_bus_name,
};
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index 79a31e5..764ec05 100644
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
@@ -580,6 +580,13 @@ static int vp_find_vqs(struct virtio_device *vdev, unsigned nvqs,
false, false);
}
+static const char *vp_bus_name(struct virtio_device *vdev)
+{
+ struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+
+ return pci_name(vp_dev->pci_dev);
+}
+
static struct virtio_config_ops virtio_pci_config_ops = {
.get = vp_get,
.set = vp_set,
@@ -590,6 +597,7 @@ static struct virtio_config_ops virtio_pci_config_ops = {
.del_vqs = vp_del_vqs,
.get_features = vp_get_features,
.finalize_features = vp_finalize_features,
+ .bus_name = vp_bus_name,
};
static void virtio_pci_release_dev(struct device *_d)
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index add4790..63f98d0 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -100,6 +100,10 @@
* vdev: the virtio_device
* This gives the final feature bits for the device: it can change
* the dev->feature bits if it wants.
+ * @bus_name: return the bus name associated with the device
+ * vdev: the virtio_device
+ * This returns a pointer to the bus name a la pci_name from which
+ * the caller can then copy.
*/
typedef void vq_callback_t(struct virtqueue *);
struct virtio_config_ops {
@@ -117,6 +121,7 @@ struct virtio_config_ops {
void (*del_vqs)(struct virtio_device *);
u32 (*get_features)(struct virtio_device *vdev);
void (*finalize_features)(struct virtio_device *vdev);
+ const char *(*bus_name)(struct virtio_device *vdev);
};
/* If driver didn't advertise the feature, it will never appear. */
@@ -182,5 +187,14 @@ struct virtqueue *virtio_find_single_vq(struct virtio_device *vdev,
return ERR_PTR(err);
return vq;
}
+
+static inline
+const char *virtio_bus_name(struct virtio_device *vdev)
+{
+ if (!vdev->config->bus_name)
+ return "virtio";
+ return vdev->config->bus_name(vdev);
+}
+
#endif /* __KERNEL__ */
#endif /* _LINUX_VIRTIO_CONFIG_H */
^ permalink raw reply related
* Re: [RFC] kvm tools: Implement multiple VQ for virtio-net
From: Krishna Kumar2 @ 2011-11-15 4:44 UTC (permalink / raw)
To: Sasha Levin
Cc: penberg, kvm, Michael S. Tsirkin, Asias He, virtualization,
gorcunov, netdev, mingo
In-Reply-To: <1321265740.2425.7.camel@sasha>
Sasha Levin <levinsasha928@gmail.com> wrote on 11/14/2011 03:45:40 PM:
> > Why both the bandwidth and latency performance are dropping so
> > dramatically with multiple VQ?
>
> It looks like theres no hash sync between host and guest, which makes
> the RX VQ change for every packet. This is my guess.
Yes, I confirmed this happens for macvtap. I am
using ixgbe - it calls skb_record_rx_queue when
a skb is allocated, but sets rxhash when a packet
arrives. Macvtap is relying on record_rx_queue
first ahead of rxhash (as part of my patch making
macvtap multiqueue), hence different skbs result
in macvtap selecting different vq's.
Reordering macvtap to use rxhash first results in
all packets going to the same VQ. The code snippet
is:
{
...
if (!numvtaps)
goto out;
rxq = skb_get_rxhash(skb);
if (rxq) {
tap = rcu_dereference(vlan->taps[rxq % numvtaps]);
if (tap)
goto out;
}
if (likely(skb_rx_queue_recorded(skb))) {
rxq = skb_get_rx_queue(skb);
while (unlikely(rxq >= numvtaps))
rxq -= numvtaps;
tap = rcu_dereference(vlan->taps[rxq]);
if (tap)
goto out;
}
}
I will submit a patch for macvtap separately. I am working
towards the other issue pointed out - different vhost
threads handling rx/tx of a single flow.
thanks,
- KK
^ permalink raw reply
* Re: [PATCH v2 09/11] virtio: net: Add freeze, restore handlers to support S4
From: Amit Shah @ 2011-11-15 12:29 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Virtualization List
In-Reply-To: <20111002093324.GD29706@redhat.com>
On (Sun) 02 Oct 2011 [11:33:26], Michael S. Tsirkin wrote:
> On Thu, Sep 29, 2011 at 09:19:40PM +0530, Amit Shah wrote:
> > Remove all the vqs on hibernation and re-create them after restoring
> > from a hibernated image. This keeps networking working across
> > hibernation.
> >
> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > ---
> > drivers/net/virtio_net.c | 28 ++++++++++++++++++++++++++++
> > 1 files changed, 28 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index dcd4b01..8b9ed43 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1131,6 +1131,30 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
> > free_netdev(vi->dev);
> > }
> >
> > +#ifdef CONFIG_PM
> > +static int virtnet_freeze(struct virtio_device *vdev)
> > +{
> > + struct virtnet_info *vi = vdev->priv;
>
> I'm guessing we need to do something like netif_device_detach here,
> otherwise guest might be in the process of using the vq for transmit at
> this point.
Done.
> I think we also must make sure NAPI RX handler is not in progress.
How to do that? napi_disable() / napi_enable() doesn't seem right
(and it doesn't work, too). pci_disable_device() in the suspend
routine may work?
> We also might need to mask interrupts from the device
> to prevent TX or RX from getting rescheduled?
pci_disable_device() will help this too, right?
Amit
^ permalink raw reply
* Re: [PATCH v2 09/11] virtio: net: Add freeze, restore handlers to support S4
From: Michael S. Tsirkin @ 2011-11-15 12:51 UTC (permalink / raw)
To: Amit Shah; +Cc: linux-kernel, Virtualization List
In-Reply-To: <20111115122902.GA26378@amit-x200.redhat.com>
On Tue, Nov 15, 2011 at 05:59:36PM +0530, Amit Shah wrote:
> On (Sun) 02 Oct 2011 [11:33:26], Michael S. Tsirkin wrote:
> > On Thu, Sep 29, 2011 at 09:19:40PM +0530, Amit Shah wrote:
> > > Remove all the vqs on hibernation and re-create them after restoring
> > > from a hibernated image. This keeps networking working across
> > > hibernation.
> > >
> > > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > > ---
> > > drivers/net/virtio_net.c | 28 ++++++++++++++++++++++++++++
> > > 1 files changed, 28 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index dcd4b01..8b9ed43 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -1131,6 +1131,30 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
> > > free_netdev(vi->dev);
> > > }
> > >
> > > +#ifdef CONFIG_PM
> > > +static int virtnet_freeze(struct virtio_device *vdev)
> > > +{
> > > + struct virtnet_info *vi = vdev->priv;
> >
> > I'm guessing we need to do something like netif_device_detach here,
> > otherwise guest might be in the process of using the vq for transmit at
> > this point.
>
> Done.
>
> > I think we also must make sure NAPI RX handler is not in progress.
>
> How to do that? napi_disable() / napi_enable() doesn't seem right
> (and it doesn't work, too). pci_disable_device() in the suspend
> routine may work?
>
> > We also might need to mask interrupts from the device
> > to prevent TX or RX from getting rescheduled?
>
> pci_disable_device() will help this too, right?
>
> Amit
No, why would it help?
--
MST
^ permalink raw reply
* Re: [PATCH 00/11] virtio: Support for hibernation (S4)
From: Amit Shah @ 2011-11-15 12:52 UTC (permalink / raw)
To: Rusty Russell; +Cc: Virtualization List, linux-kernel, Michael S. Tsirkin
In-Reply-To: <8739f9ipsi.fsf@rustcorp.com.au>
On (Tue) 04 Oct 2011 [10:36:05], Rusty Russell wrote:
> On Sun, 2 Oct 2011 11:49:21 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Thu, Sep 29, 2011 at 08:55:56PM +0530, Amit Shah wrote:
> > > Hello,
> > >
> > > These patches add support for S4 to virtio (pci) and all drivers. The
> > > patches are based on the virtio-console patch series in Rusty's queue.
> > >
> > > For each driver, all vqs are removed before hibernation, and then
> > > re-created after restore.
> > >
> > > All the drivers in testing work fine:
> > >
> > > * virtio-blk is used for the only disk in the VM, IO works fine before
> > > and after.
>
> I'm not familiar with the suspend code, but:
>
> 1) Does it already ensure there are no outstanding I/O requests? If
> not, we want to restore them when we unfreeze.
For the blk code, I added blk_drain_queue() and related calls to the
freeze handler, that was missed earlier.
> 2) Does it stop more I/O from reaching do_virtblk_request during freeze?
> If not, we need to.
Added blk_stop_queue() and blk_start_queue() calls to ensure this.
> If we need to save and restore requests, I don't think we should do this
> on a per-driver basis, but try to do it in the core.
Agreed, however currently we don't save and restore any pending vq
items. If it is necessary, we should do it in common code (earlier
version of this patchset did that). I think we can get better results
by flushing the vq instead of trying to save/restore elements.
Amit
^ permalink raw reply
* Re: [RFC 0/5] virtio-pci,kvm tools: Support new virtio-pci spec in kvm tools
From: Michael S. Tsirkin @ 2011-11-15 12:59 UTC (permalink / raw)
To: Sasha Levin; +Cc: kvm, linux-kernel, virtualization, penberg, mingo
In-Reply-To: <1321314197-5265-1-git-send-email-levinsasha928@gmail.com>
On Tue, Nov 15, 2011 at 01:43:12AM +0200, Sasha Levin wrote:
> This patch series contains two fixes for the RFC patch send by Michael. These
> patches are pretty basic and should probably be merged into the next version
> of that patch.
Yes, will do, thanks!
> Other two patches add support to the new virtio-pci spec in KVM tools, allowing
> for easy testing of any future virtio-pci kernel side patches. The usermode code
> isn't complete, but it's working properly and should be enough for functionality
> testing.
>
> Michael S. Tsirkin (1):
> virtio-pci: flexible configuration layout
>
> Sasha Levin (4):
> virtio-pci: Fix compilation issue
> iomap: Don't ignore offset
> kvm tools: Free up the MSI-X PBA BAR
> kvm tools: Support new virtio-pci configuration layout
>
> drivers/virtio/virtio_pci.c | 184 ++++++++++++++++++++++--
> include/asm-generic/io.h | 4 +
> include/asm-generic/iomap.h | 11 ++
> include/linux/pci_regs.h | 4 +
> include/linux/virtio_pci.h | 41 ++++++
> lib/iomap.c | 41 +++++-
> tools/kvm/include/kvm/pci.h | 13 ++-
> tools/kvm/include/kvm/virtio-pci.h | 5 +-
> tools/kvm/virtio/pci.c | 275 ++++++++++++++++++++++++++++++++----
> 9 files changed, 530 insertions(+), 48 deletions(-)
>
> --
> 1.7.8.rc1
^ permalink raw reply
* [PATCH] virtio-mmio: Devices parameter parsing
From: Pawel Moll @ 2011-11-15 13:53 UTC (permalink / raw)
To: Rusty Russell, linux-kernel, virtualization
Cc: Peter Maydell, Sasha Levin, Pawel Moll
This patch adds an option to instantiate guest virtio-mmio devices
basing on a kernel command line (or module) parameter, for example:
virtio_mmio.devices=0x100@0x100b0000:48,1K@0x1001e000:74
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
drivers/virtio/Kconfig | 25 ++++++
drivers/virtio/virtio_mmio.c | 170 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 194 insertions(+), 1 deletions(-)
Hi All,
When Sasha asked me if there is any way of instantiating the mmio devices
from kernel command line I answered no and that I believed that the correct
way of doing that would be passing a Device Tree with it. But then someone
else asked me the same so I figured out that I was probably wrong and there
is a need for that...
Here it goes, then. As it's easy to shoot yourself in the foot with that
(just specify bogus base address and watch as your system is going to hell ;-)
it's an option that must be explicitly enabled.
I hope it will be useful in DT-less qemu/KVM use cases.
All comments most welcomed!
Cheers!
Pawel
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 816ed08..61f3a79 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -46,4 +46,29 @@ config VIRTIO_BALLOON
If unsure, say N.
+config VIRTIO_MMIO_CMDLINE_DEVICES
+ bool "Memory mapped virtio devices parameter parsing"
+ depends on VIRTIO_MMIO
+ ---help---
+ Allow virtio-mmio devices instantiation via the kernel command line
+ or module parameter. Be aware that using incorrect parameters (base
+ address in particular) can crash your system - you have been warned.
+
+ The format for the parameter is as follows:
+
+ [virtio_mmio.]devices=<device>[<delim><device>]
+
+ where:
+ <device> := <size>@<baseaddr>:<irq>
+ <delim> := ',' or ';'
+ <size> := size (can use standard suffixes like K or M)
+ <baseaddr> := physical base address
+ <irq> := interrupt number (as passed to request_irq())
+
+ Example kernel command line parameter:
+
+ virtio_mmio.devices=0x100@0x100b0000:48,1K@0x1001e000:74
+
+ If unsure, say 'N'.
+
endmenu
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index acc5e43..1f25bb9 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -6,6 +6,47 @@
* This module allows virtio devices to be used over a virtual, memory mapped
* platform device.
*
+ * The guest device(s) may be instantiated in one of three equivalent ways:
+ *
+ * 1. Static platform device in board's code, eg.:
+ *
+ * static struct platform_device v2m_virtio_device = {
+ * .name = "virtio-mmio",
+ * .id = -1,
+ * .num_resources = 2,
+ * .resource = (struct resource []) {
+ * {
+ * .start = 0x1001e000,
+ * .end = 0x1001e0ff,
+ * .flags = IORESOURCE_MEM,
+ * }, {
+ * .start = 42 + 32,
+ * .end = 42 + 32,
+ * .flags = IORESOURCE_IRQ,
+ * },
+ * }
+ * };
+ *
+ * 2. Device Tree node, eg.:
+ *
+ * virtio_block@1e000 {
+ * compatible = "virtio,mmio";
+ * reg = <0x1e000 0x100>;
+ * interrupts = <42>;
+ * }
+ *
+ * 3. Kernel module (or command line) parameter
+ * [virtio_mmio.]devices=<device>[<delim><device>]
+ * where:
+ * <device> := <size>@<baseaddr>:<irq>
+ * <delim> := ',' or ';'
+ * <size> := size (can use standard suffixes like K or M)
+ * <baseaddr> := physical base address
+ * <irq> := interrupt number (as passed to request_irq())
+ * eg.:
+ * virtio_mmio.devices=0x100@0x100b0000:48,1K@0x1001e000:74
+ *
+ *
* Registers layout (all 32-bit wide):
*
* offset d. name description
@@ -42,6 +83,8 @@
* See the COPYING file in the top-level directory.
*/
+#define pr_fmt(fmt) "virtio-mmio: " fmt
+
#include <linux/highmem.h>
#include <linux/interrupt.h>
#include <linux/io.h>
@@ -443,6 +486,127 @@ static int __devexit virtio_mmio_remove(struct platform_device *pdev)
+/* Devices list parameter */
+
+#if defined(CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES)
+
+static char *virtio_mmio_cmdline_devices;
+module_param_named(devices, virtio_mmio_cmdline_devices, charp, 0);
+
+static struct device virtio_mmio_cmdline_parent = {
+ .init_name = "virtio-mmio-cmdline",
+};
+
+static int virtio_mmio_register_cmdline_devices(void)
+{
+ int err;
+ int id = 0;
+ char *device = NULL;
+ char *token;
+
+ err = device_register(&virtio_mmio_cmdline_parent);
+ if (err)
+ return err;
+
+ /* Split colon-or-semicolon-separated devices */
+ while ((token = strsep(&virtio_mmio_cmdline_devices, ",;")) != NULL) {
+ struct resource resources[] = {
+ {
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .flags = IORESOURCE_MEM,
+ }
+ };
+ char *size, *base;
+ unsigned long long val;
+
+ if (!*token)
+ continue;
+
+ kfree(device);
+ device = kstrdup(token, GFP_KERNEL);
+
+ /* Split memory and IRQ resources */
+ base = strsep(&token, ":");
+ if (base == token || !token || !*token) {
+ pr_err("No IRQ in '%s'!\n", device);
+ continue;
+ }
+
+ /* Get IRQ */
+ if (kstrtoull(token, 0, &val) != 0) {
+ pr_err("Wrong IRQ in '%s'!\n", device);
+ continue;
+ }
+ resources[0].start = val;
+ resources[0].end = val;
+
+ /* Split base address and size */
+ size = strsep(&base, "@");
+ if (size == base || !base || !*base) {
+ pr_err("No base in '%s'!\n", device);
+ continue;
+ }
+
+ /* Get base address */
+ if (kstrtoull(base, 0, &val) != 0) {
+ pr_err("Wrong base in '%s'!\n", device);
+ continue;
+ }
+ resources[1].start = val;
+ resources[1].end = val;
+
+ /* Get size */
+ resources[1].end += memparse(size, &token) - 1;
+ if (size == token || *token) {
+ pr_err("Wrong size in '%s'!\n", device);
+ continue;
+ }
+
+ pr_info("Registering device %d at 0x%x-0x%x, IRQ %u.\n",
+ id, resources[1].start, resources[1].end,
+ resources[0].start);
+
+ platform_device_register_resndata(&virtio_mmio_cmdline_parent,
+ "virtio-mmio", id, resources,
+ ARRAY_SIZE(resources), NULL, 0);
+
+ id++;
+ }
+
+ kfree(device);
+
+ return 0;
+}
+
+static int virtio_mmio_unregister_cmdline_device(struct device *dev,
+ void *data)
+{
+ platform_device_unregister(to_platform_device(dev));
+
+ return 0;
+}
+
+static void virtio_mmio_unregister_cmdline_devices(void)
+{
+ device_for_each_child(&virtio_mmio_cmdline_parent, NULL,
+ virtio_mmio_unregister_cmdline_device);
+ device_unregister(&virtio_mmio_cmdline_parent);
+}
+
+#else
+
+static int virtio_mmio_register_cmdline_devices(void)
+{
+ return 0;
+}
+
+static void virtio_mmio_unregister_cmdline_devices(void)
+{
+}
+
+#endif
+
/* Platform driver */
static struct of_device_id virtio_mmio_match[] = {
@@ -463,11 +627,15 @@ static struct platform_driver virtio_mmio_driver = {
static int __init virtio_mmio_init(void)
{
- return platform_driver_register(&virtio_mmio_driver);
+ int err = virtio_mmio_register_cmdline_devices();
+
+ return err ? err : platform_driver_register(&virtio_mmio_driver);
}
static void __exit virtio_mmio_exit(void)
{
+ virtio_mmio_unregister_cmdline_devices();
+
platform_driver_unregister(&virtio_mmio_driver);
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH v2 09/11] virtio: net: Add freeze, restore handlers to support S4
From: Amit Shah @ 2011-11-15 14:03 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Virtualization List
In-Reply-To: <20111115125127.GA31208@redhat.com>
On (Tue) 15 Nov 2011 [14:51:27], Michael S. Tsirkin wrote:
> On Tue, Nov 15, 2011 at 05:59:36PM +0530, Amit Shah wrote:
> > On (Sun) 02 Oct 2011 [11:33:26], Michael S. Tsirkin wrote:
> > > On Thu, Sep 29, 2011 at 09:19:40PM +0530, Amit Shah wrote:
> > > > Remove all the vqs on hibernation and re-create them after restoring
> > > > from a hibernated image. This keeps networking working across
> > > > hibernation.
> > > >
> > > > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > > > ---
> > > > drivers/net/virtio_net.c | 28 ++++++++++++++++++++++++++++
> > > > 1 files changed, 28 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index dcd4b01..8b9ed43 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -1131,6 +1131,30 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
> > > > free_netdev(vi->dev);
> > > > }
> > > >
> > > > +#ifdef CONFIG_PM
> > > > +static int virtnet_freeze(struct virtio_device *vdev)
> > > > +{
> > > > + struct virtnet_info *vi = vdev->priv;
> > >
> > > I'm guessing we need to do something like netif_device_detach here,
> > > otherwise guest might be in the process of using the vq for transmit at
> > > this point.
> >
> > Done.
> >
> > > I think we also must make sure NAPI RX handler is not in progress.
> >
> > How to do that? napi_disable() / napi_enable() doesn't seem right
> > (and it doesn't work, too). pci_disable_device() in the suspend
> > routine may work?
> >
> > > We also might need to mask interrupts from the device
> > > to prevent TX or RX from getting rescheduled?
> >
> > pci_disable_device() will help this too, right?
> >
> > Amit
>
> No, why would it help?
IRQs will be disabled after the call to pci_disable_device(), isn't
that sufficient?
Amit
^ permalink raw reply
* [PATCH] virtio-mmio: Correct the name of the guest features selector
From: Sasha Levin @ 2011-11-15 14:17 UTC (permalink / raw)
To: linux-kernel; +Cc: Sasha Levin, Pawel Moll, virtualization
Guest features selector spelling mistake.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
Hopefully not too late to fix, should possibly be done in one of the next RCs
since it's user facing.
include/linux/virtio_mmio.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/virtio_mmio.h b/include/linux/virtio_mmio.h
index 27c7ede..5c7b6f0 100644
--- a/include/linux/virtio_mmio.h
+++ b/include/linux/virtio_mmio.h
@@ -63,7 +63,7 @@
#define VIRTIO_MMIO_GUEST_FEATURES 0x020
/* Activated features set selector - Write Only */
-#define VIRTIO_MMIO_GUEST_FEATURES_SET 0x024
+#define VIRTIO_MMIO_GUEST_FEATURES_SEL 0x024
/* Guest's memory page size in bytes - Write Only */
#define VIRTIO_MMIO_GUEST_PAGE_SIZE 0x028
--
1.7.8.rc1
^ permalink raw reply related
* Re: [PATCH v2 09/11] virtio: net: Add freeze, restore handlers to support S4
From: Michael S. Tsirkin @ 2011-11-15 14:23 UTC (permalink / raw)
To: Amit Shah; +Cc: linux-kernel, Virtualization List
In-Reply-To: <20111115140346.GC26378@amit-x200.redhat.com>
On Tue, Nov 15, 2011 at 07:33:46PM +0530, Amit Shah wrote:
> On (Tue) 15 Nov 2011 [14:51:27], Michael S. Tsirkin wrote:
> > On Tue, Nov 15, 2011 at 05:59:36PM +0530, Amit Shah wrote:
> > > On (Sun) 02 Oct 2011 [11:33:26], Michael S. Tsirkin wrote:
> > > > On Thu, Sep 29, 2011 at 09:19:40PM +0530, Amit Shah wrote:
> > > > > Remove all the vqs on hibernation and re-create them after restoring
> > > > > from a hibernated image. This keeps networking working across
> > > > > hibernation.
> > > > >
> > > > > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > > > > ---
> > > > > drivers/net/virtio_net.c | 28 ++++++++++++++++++++++++++++
> > > > > 1 files changed, 28 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > index dcd4b01..8b9ed43 100644
> > > > > --- a/drivers/net/virtio_net.c
> > > > > +++ b/drivers/net/virtio_net.c
> > > > > @@ -1131,6 +1131,30 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
> > > > > free_netdev(vi->dev);
> > > > > }
> > > > >
> > > > > +#ifdef CONFIG_PM
> > > > > +static int virtnet_freeze(struct virtio_device *vdev)
> > > > > +{
> > > > > + struct virtnet_info *vi = vdev->priv;
> > > >
> > > > I'm guessing we need to do something like netif_device_detach here,
> > > > otherwise guest might be in the process of using the vq for transmit at
> > > > this point.
> > >
> > > Done.
> > >
> > > > I think we also must make sure NAPI RX handler is not in progress.
> > >
> > > How to do that? napi_disable() / napi_enable() doesn't seem right
> > > (and it doesn't work, too). pci_disable_device() in the suspend
> > > routine may work?
> > >
> > > > We also might need to mask interrupts from the device
> > > > to prevent TX or RX from getting rescheduled?
> > >
> > > pci_disable_device() will help this too, right?
> > >
> > > Amit
> >
> > No, why would it help?
>
> IRQs will be disabled after the call to pci_disable_device(),
> isn't that sufficient?
>
> Amit
They will?
* pci_disable_device - Disable PCI device after use
* @dev: PCI device to be disabled
*
* Signal to the system that the PCI device is not in use by the system
* anymore. This only involves disabling PCI bus-mastering, if active.
*
* Note we don't actually disable the device until all callers of
* pci_enable_device() have called pci_disable_device().
--
MST
^ permalink raw reply
* Re: [PATCH] virtio-mmio: Correct the name of the guest features selector
From: Pawel Moll @ 2011-11-15 14:25 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <1321366638-28408-1-git-send-email-levinsasha928@gmail.com>
On Tue, 2011-11-15 at 14:17 +0000, Sasha Levin wrote:
> Guest features selector spelling mistake.
>
> diff --git a/include/linux/virtio_mmio.h b/include/linux/virtio_mmio.h
> index 27c7ede..5c7b6f0 100644
> --- a/include/linux/virtio_mmio.h
> +++ b/include/linux/virtio_mmio.h
> @@ -63,7 +63,7 @@
> #define VIRTIO_MMIO_GUEST_FEATURES 0x020
>
> /* Activated features set selector - Write Only */
> -#define VIRTIO_MMIO_GUEST_FEATURES_SET 0x024
> +#define VIRTIO_MMIO_GUEST_FEATURES_SEL 0x024
>
> /* Guest's memory page size in bytes - Write Only */
> #define VIRTIO_MMIO_GUEST_PAGE_SIZE 0x028
Damn. Sorry about it. But if you change the header you'll need to change
the driver:
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 1f25bb9..10bb8b9 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -161,7 +161,7 @@ static void vm_finalize_features(struct virtio_device *vdev)
vring_transport_features(vdev);
for (i = 0; i < ARRAY_SIZE(vdev->features); i++) {
- writel(i, vm_dev->base + VIRTIO_MMIO_GUEST_FEATURES_SET);
+ writel(i, vm_dev->base + VIRTIO_MMIO_GUEST_FEATURES_SEL);
writel(vdev->features[i],
vm_dev->base + VIRTIO_MMIO_GUEST_FEATURES);
}
Cheers!
Paweł
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* Re: [PATCH v2 09/11] virtio: net: Add freeze, restore handlers to support S4
From: Amit Shah @ 2011-11-15 14:31 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Virtualization List
In-Reply-To: <20111115142259.GA16395@redhat.com>
On (Tue) 15 Nov 2011 [16:23:00], Michael S. Tsirkin wrote:
> On Tue, Nov 15, 2011 at 07:33:46PM +0530, Amit Shah wrote:
> > On (Tue) 15 Nov 2011 [14:51:27], Michael S. Tsirkin wrote:
> > > On Tue, Nov 15, 2011 at 05:59:36PM +0530, Amit Shah wrote:
> > > > On (Sun) 02 Oct 2011 [11:33:26], Michael S. Tsirkin wrote:
> > > > > On Thu, Sep 29, 2011 at 09:19:40PM +0530, Amit Shah wrote:
> > > > > > Remove all the vqs on hibernation and re-create them after restoring
> > > > > > from a hibernated image. This keeps networking working across
> > > > > > hibernation.
> > > > > >
> > > > > > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > > > > > ---
> > > > > > drivers/net/virtio_net.c | 28 ++++++++++++++++++++++++++++
> > > > > > 1 files changed, 28 insertions(+), 0 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > > index dcd4b01..8b9ed43 100644
> > > > > > --- a/drivers/net/virtio_net.c
> > > > > > +++ b/drivers/net/virtio_net.c
> > > > > > @@ -1131,6 +1131,30 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
> > > > > > free_netdev(vi->dev);
> > > > > > }
> > > > > >
> > > > > > +#ifdef CONFIG_PM
> > > > > > +static int virtnet_freeze(struct virtio_device *vdev)
> > > > > > +{
> > > > > > + struct virtnet_info *vi = vdev->priv;
> > > > >
> > > > > I'm guessing we need to do something like netif_device_detach here,
> > > > > otherwise guest might be in the process of using the vq for transmit at
> > > > > this point.
> > > >
> > > > Done.
> > > >
> > > > > I think we also must make sure NAPI RX handler is not in progress.
> > > >
> > > > How to do that? napi_disable() / napi_enable() doesn't seem right
> > > > (and it doesn't work, too). pci_disable_device() in the suspend
> > > > routine may work?
> > > >
> > > > > We also might need to mask interrupts from the device
> > > > > to prevent TX or RX from getting rescheduled?
> > > >
> > > > pci_disable_device() will help this too, right?
> > > >
> > >
> > > No, why would it help?
> >
> > IRQs will be disabled after the call to pci_disable_device(),
> > isn't that sufficient?
> >
>
> They will?
> * pci_disable_device - Disable PCI device after use
> * @dev: PCI device to be disabled
> *
> * Signal to the system that the PCI device is not in use by the system
> * anymore. This only involves disabling PCI bus-mastering, if active.
> *
> * Note we don't actually disable the device until all callers of
> * pci_enable_device() have called pci_disable_device().
You mean multiple devices could have called pci_enable_device()? Not
likely to happen, at least in case of our virtio devices... only we
claim ownership over them. I don't think that'll change.
Amit
^ permalink raw reply
* Re: [PATCH v2 09/11] virtio: net: Add freeze, restore handlers to support S4
From: Michael S. Tsirkin @ 2011-11-15 14:36 UTC (permalink / raw)
To: Amit Shah; +Cc: linux-kernel, Virtualization List
In-Reply-To: <20111115143149.GE26378@amit-x200.redhat.com>
On Tue, Nov 15, 2011 at 08:01:49PM +0530, Amit Shah wrote:
> On (Tue) 15 Nov 2011 [16:23:00], Michael S. Tsirkin wrote:
> > On Tue, Nov 15, 2011 at 07:33:46PM +0530, Amit Shah wrote:
> > > On (Tue) 15 Nov 2011 [14:51:27], Michael S. Tsirkin wrote:
> > > > On Tue, Nov 15, 2011 at 05:59:36PM +0530, Amit Shah wrote:
> > > > > On (Sun) 02 Oct 2011 [11:33:26], Michael S. Tsirkin wrote:
> > > > > > On Thu, Sep 29, 2011 at 09:19:40PM +0530, Amit Shah wrote:
> > > > > > > Remove all the vqs on hibernation and re-create them after restoring
> > > > > > > from a hibernated image. This keeps networking working across
> > > > > > > hibernation.
> > > > > > >
> > > > > > > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > > > > > > ---
> > > > > > > drivers/net/virtio_net.c | 28 ++++++++++++++++++++++++++++
> > > > > > > 1 files changed, 28 insertions(+), 0 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > > > index dcd4b01..8b9ed43 100644
> > > > > > > --- a/drivers/net/virtio_net.c
> > > > > > > +++ b/drivers/net/virtio_net.c
> > > > > > > @@ -1131,6 +1131,30 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
> > > > > > > free_netdev(vi->dev);
> > > > > > > }
> > > > > > >
> > > > > > > +#ifdef CONFIG_PM
> > > > > > > +static int virtnet_freeze(struct virtio_device *vdev)
> > > > > > > +{
> > > > > > > + struct virtnet_info *vi = vdev->priv;
> > > > > >
> > > > > > I'm guessing we need to do something like netif_device_detach here,
> > > > > > otherwise guest might be in the process of using the vq for transmit at
> > > > > > this point.
> > > > >
> > > > > Done.
> > > > >
> > > > > > I think we also must make sure NAPI RX handler is not in progress.
> > > > >
> > > > > How to do that? napi_disable() / napi_enable() doesn't seem right
> > > > > (and it doesn't work, too). pci_disable_device() in the suspend
> > > > > routine may work?
> > > > >
> > > > > > We also might need to mask interrupts from the device
> > > > > > to prevent TX or RX from getting rescheduled?
> > > > >
> > > > > pci_disable_device() will help this too, right?
> > > > >
> > > >
> > > > No, why would it help?
> > >
> > > IRQs will be disabled after the call to pci_disable_device(),
> > > isn't that sufficient?
> > >
> >
> > They will?
> > * pci_disable_device - Disable PCI device after use
> > * @dev: PCI device to be disabled
> > *
> > * Signal to the system that the PCI device is not in use by the system
> > * anymore. This only involves disabling PCI bus-mastering, if active.
> > *
> > * Note we don't actually disable the device until all callers of
> > * pci_enable_device() have called pci_disable_device().
>
> You mean multiple devices could have called pci_enable_device()? Not
> likely to happen, at least in case of our virtio devices... only we
> claim ownership over them. I don't think that'll change.
>
> Amit
I simply mean that pci_disable_device does not seem to disable
interrupts.
--
MST
^ permalink raw reply
* Re: [RFC] kvm tools: Implement multiple VQ for virtio-net
From: Sasha Levin @ 2011-11-15 15:30 UTC (permalink / raw)
To: Krishna Kumar2
Cc: penberg, kvm, Michael S. Tsirkin, Asias He, virtualization,
gorcunov, netdev, mingo
In-Reply-To: <OFDA747DDD.8D1C8FD8-ON65257949.001837DA-65257949.0019D25F@in.ibm.com>
On Tue, 2011-11-15 at 10:14 +0530, Krishna Kumar2 wrote:
> Sasha Levin <levinsasha928@gmail.com> wrote on 11/14/2011 03:45:40 PM:
>
> > > Why both the bandwidth and latency performance are dropping so
> > > dramatically with multiple VQ?
> >
> > It looks like theres no hash sync between host and guest, which makes
> > the RX VQ change for every packet. This is my guess.
>
> Yes, I confirmed this happens for macvtap. I am
> using ixgbe - it calls skb_record_rx_queue when
> a skb is allocated, but sets rxhash when a packet
> arrives. Macvtap is relying on record_rx_queue
> first ahead of rxhash (as part of my patch making
> macvtap multiqueue), hence different skbs result
> in macvtap selecting different vq's.
I'm seeing this behavior in non-macvtep related setup as well (simple
tap <-> virtio-net).
--
Sasha.
^ permalink raw reply
* Re: [PATCH v2 09/11] virtio: net: Add freeze, restore handlers to support S4
From: Amit Shah @ 2011-11-15 15:37 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Virtualization List
In-Reply-To: <20111115143620.GA16609@redhat.com>
On (Tue) 15 Nov 2011 [16:36:20], Michael S. Tsirkin wrote:
> On Tue, Nov 15, 2011 at 08:01:49PM +0530, Amit Shah wrote:
> > On (Tue) 15 Nov 2011 [16:23:00], Michael S. Tsirkin wrote:
> > > On Tue, Nov 15, 2011 at 07:33:46PM +0530, Amit Shah wrote:
> > > > On (Tue) 15 Nov 2011 [14:51:27], Michael S. Tsirkin wrote:
> > > > > On Tue, Nov 15, 2011 at 05:59:36PM +0530, Amit Shah wrote:
> > > > > > On (Sun) 02 Oct 2011 [11:33:26], Michael S. Tsirkin wrote:
> > > > > > > On Thu, Sep 29, 2011 at 09:19:40PM +0530, Amit Shah wrote:
> > > > > > > > Remove all the vqs on hibernation and re-create them after restoring
> > > > > > > > from a hibernated image. This keeps networking working across
> > > > > > > > hibernation.
> > > > > > > >
> > > > > > > > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > > > > > > > ---
> > > > > > > > drivers/net/virtio_net.c | 28 ++++++++++++++++++++++++++++
> > > > > > > > 1 files changed, 28 insertions(+), 0 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > > > > index dcd4b01..8b9ed43 100644
> > > > > > > > --- a/drivers/net/virtio_net.c
> > > > > > > > +++ b/drivers/net/virtio_net.c
> > > > > > > > @@ -1131,6 +1131,30 @@ static void __devexit virtnet_remove(struct virtio_device *vdev)
> > > > > > > > free_netdev(vi->dev);
> > > > > > > > }
> > > > > > > >
> > > > > > > > +#ifdef CONFIG_PM
> > > > > > > > +static int virtnet_freeze(struct virtio_device *vdev)
> > > > > > > > +{
> > > > > > > > + struct virtnet_info *vi = vdev->priv;
> > > > > > >
> > > > > > > I'm guessing we need to do something like netif_device_detach here,
> > > > > > > otherwise guest might be in the process of using the vq for transmit at
> > > > > > > this point.
> > > > > >
> > > > > > Done.
> > > > > >
> > > > > > > I think we also must make sure NAPI RX handler is not in progress.
> > > > > >
> > > > > > How to do that? napi_disable() / napi_enable() doesn't seem right
> > > > > > (and it doesn't work, too). pci_disable_device() in the suspend
> > > > > > routine may work?
> > > > > >
> > > > > > > We also might need to mask interrupts from the device
> > > > > > > to prevent TX or RX from getting rescheduled?
> > > > > >
> > > > > > pci_disable_device() will help this too, right?
> > > > > >
> > > > >
> > > > > No, why would it help?
> > > >
> > > > IRQs will be disabled after the call to pci_disable_device(),
> > > > isn't that sufficient?
> > > >
> > >
> > > They will?
> > > * pci_disable_device - Disable PCI device after use
> > > * @dev: PCI device to be disabled
> > > *
> > > * Signal to the system that the PCI device is not in use by the system
> > > * anymore. This only involves disabling PCI bus-mastering, if active.
> > > *
> > > * Note we don't actually disable the device until all callers of
> > > * pci_enable_device() have called pci_disable_device().
> >
> > You mean multiple devices could have called pci_enable_device()? Not
> > likely to happen, at least in case of our virtio devices... only we
> > claim ownership over them. I don't think that'll change.
> >
>
> I simply mean that pci_disable_device does not seem to disable
> interrupts.
As far as I know, all our irqs are allocated for vqs, and they'll be
freed when the vqs are freed too.
Are there any others that need special handling?
Amit
^ permalink raw reply
* [RFC] kvm tools: Add support for virtio-mmio
From: Sasha Levin @ 2011-11-15 16:47 UTC (permalink / raw)
To: penberg
Cc: Peter Maydell, kvm, Pawel Moll, asias.hejun, virtualization,
gorcunov, Sasha Levin, mingo
This patch adds support for the new virtio-mmio transport layer added in
3.2-rc1.
The purpose of this new layer is to allow virtio to work on systems which
don't necessarily support PCI, such as embedded systems.
To apply the patch on top of the KVM tools tree, you must first pull Linus'
tree on top. Also, CONFIG_VIRTIO_MMIO=y should be set in the guest kernel.
This is an early RFC, command line currently only supports virtio-net
(although this can be easily extended). ioeventfds and VQ size/align
still unsupported (but will work on x86).
To easily test it it's recommended to apply Pawel Moll's patch named
'virtio-mmio: Devices parameter parsing' on top, and define the virtio-mmio
device using kernel command line.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
tools/kvm/Makefile | 1 +
tools/kvm/builtin-run.c | 2 +
tools/kvm/include/kvm/virtio-mmio.h | 61 ++++++++++++
tools/kvm/include/kvm/virtio-net.h | 1 +
tools/kvm/include/kvm/virtio-trans.h | 1 +
tools/kvm/virtio/mmio.c | 177 ++++++++++++++++++++++++++++++++++
tools/kvm/virtio/net.c | 8 +-
tools/kvm/virtio/trans.c | 11 ++
8 files changed, 260 insertions(+), 2 deletions(-)
create mode 100644 tools/kvm/include/kvm/virtio-mmio.h
create mode 100644 tools/kvm/virtio/mmio.c
diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index bb5f6b0..449651c 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -84,6 +84,7 @@ OBJS += hw/vesa.o
OBJS += hw/i8042.o
OBJS += hw/pci-shmem.o
OBJS += kvm-ipc.o
+OBJS += virtio/mmio.o
FLAGS_BFD := $(CFLAGS) -lbfd
has_bfd := $(call try-cc,$(SOURCE_BFD),$(FLAGS_BFD))
diff --git a/tools/kvm/builtin-run.c b/tools/kvm/builtin-run.c
index 13025db..1701202 100644
--- a/tools/kvm/builtin-run.c
+++ b/tools/kvm/builtin-run.c
@@ -217,6 +217,8 @@ static int set_net_param(struct virtio_net_params *p, const char *param,
p->guest_ip = strdup(val);
} else if (strcmp(param, "host_ip") == 0) {
p->host_ip = strdup(val);
+ } else if (strcmp(param, "virtio_trans") == 0) {
+ p->virtio_trans = strdup(val);
}
return 0;
diff --git a/tools/kvm/include/kvm/virtio-mmio.h b/tools/kvm/include/kvm/virtio-mmio.h
new file mode 100644
index 0000000..1b07df1
--- /dev/null
+++ b/tools/kvm/include/kvm/virtio-mmio.h
@@ -0,0 +1,61 @@
+#ifndef KVM__VIRTIO_MMIO_H
+#define KVM__VIRTIO_MMIO_H
+
+#include "kvm/virtio-trans.h"
+
+#include <linux/types.h>
+#include <linux/virtio_mmio.h>
+
+#define VIRTIO_MMIO_MAX_VQ 3
+#define VIRTIO_MMIO_MAX_CONFIG 1
+
+struct kvm;
+
+struct virtio_mmio_ioevent_param {
+ struct virtio_trans *vtrans;
+ u32 vq;
+};
+
+struct virtio_mmio_hdr {
+ char magic[4];
+ u32 version;
+ u32 device_id;
+ u32 vendor_id;
+ u32 host_features;
+ u32 host_features_sel;
+ u64 reserved_1;
+ u32 guest_features;
+ u32 guest_features_sel;
+ u32 guest_page_size;
+ u32 reserved_2;
+ u32 queue_sel;
+ u32 queue_num_max;
+ u32 queue_num;
+ u32 queue_align;
+ u32 queue_pfn;
+ u32 reserved_3[3];
+ u32 queue_notify;
+ u32 reserved_4[3];
+ u32 interrupt_state;
+ u32 interrupt_ack;
+ u32 status;
+};
+
+struct virtio_mmio {
+ u32 addr;
+ void *dev;
+ struct kvm *kvm;
+
+ u8 irq;
+ struct virtio_mmio_hdr hdr;
+ //struct virtio_mmio_ioevent_param ioeventfds[VIRTIO_MMIO_MAX_VQ];
+};
+
+int virtio_mmio__init(struct kvm *kvm, struct virtio_trans *vtrans, void *dev,
+ int device_id, int subsys_id, int class);
+int virtio_mmio__signal_vq(struct kvm *kvm, struct virtio_trans *vtrans, u32 vq);
+int virtio_mmio__signal_config(struct kvm *kvm, struct virtio_trans *vtrans);
+
+struct virtio_trans_ops *virtio_mmio__get_trans_ops(void);
+
+#endif
diff --git a/tools/kvm/include/kvm/virtio-net.h b/tools/kvm/include/kvm/virtio-net.h
index 58ae162..a419dc7 100644
--- a/tools/kvm/include/kvm/virtio-net.h
+++ b/tools/kvm/include/kvm/virtio-net.h
@@ -7,6 +7,7 @@ struct virtio_net_params {
const char *guest_ip;
const char *host_ip;
const char *script;
+ const char *virtio_trans;
char guest_mac[6];
char host_mac[6];
struct kvm *kvm;
diff --git a/tools/kvm/include/kvm/virtio-trans.h b/tools/kvm/include/kvm/virtio-trans.h
index d9f4b95..5e69335 100644
--- a/tools/kvm/include/kvm/virtio-trans.h
+++ b/tools/kvm/include/kvm/virtio-trans.h
@@ -5,6 +5,7 @@
enum virtio_trans_type {
VIRTIO_PCI,
+ VIRTIO_MMIO,
};
struct virtio_trans;
diff --git a/tools/kvm/virtio/mmio.c b/tools/kvm/virtio/mmio.c
new file mode 100644
index 0000000..1449b04
--- /dev/null
+++ b/tools/kvm/virtio/mmio.c
@@ -0,0 +1,177 @@
+#include "kvm/virtio-mmio.h"
+
+#include "kvm/ioport.h"
+#include "kvm/kvm.h"
+#include "kvm/irq.h"
+#include "kvm/virtio.h"
+#include "kvm/ioeventfd.h"
+#include "kvm/virtio-trans.h"
+#include "kvm/virtio-mmio.h"
+#include "kvm/pci.h"
+#include "kvm/virtio-pci-dev.h"
+#include "kvm/util.h"
+
+#include <linux/virtio_mmio.h>
+#include <string.h>
+
+struct virtio_trans_ops *virtio_mmio__get_trans_ops(void)
+{
+ static struct virtio_trans_ops virtio_pci_trans = (struct virtio_trans_ops) {
+ .signal_vq = virtio_mmio__signal_vq,
+ .signal_config = virtio_mmio__signal_config,
+ .init = virtio_mmio__init,
+ };
+ return &virtio_pci_trans;
+};
+
+int virtio_mmio__signal_vq(struct kvm *kvm, struct virtio_trans *vtrans, u32 vq)
+{
+ struct virtio_mmio *vmmio = vtrans->virtio;
+
+ vmmio->hdr.interrupt_state |= VIRTIO_MMIO_INT_VRING;
+ kvm__irq_trigger(vmmio->kvm, vmmio->irq);
+
+ return 0;
+}
+
+int virtio_mmio__signal_config(struct kvm *kvm, struct virtio_trans *vtrans)
+{
+ struct virtio_mmio *vmmio = vtrans->virtio;
+
+ vmmio->hdr.interrupt_state |= VIRTIO_MMIO_INT_CONFIG;
+ kvm__irq_trigger(vmmio->kvm, vmmio->irq);
+
+ return 0;
+}
+
+static void virtio_mmio__device_specific(u64 addr, u8 *data, u32 len, u8 is_write,
+ struct virtio_trans *vtrans)
+{
+ struct virtio_mmio *vmmio = vtrans->virtio;
+ u32 i;
+
+ for (i = 0; i < len; i++) {
+ if (is_write)
+ vtrans->virtio_ops->set_config(vmmio->kvm, vmmio->dev,
+ *(u8 *)data + i, addr + i);
+ else
+ data[i] =
+ vtrans->virtio_ops->get_config(vmmio->kvm, vmmio->dev, addr + i);
+ }
+}
+
+static void virtio_mmio__config_out(u64 addr, void *data, u32 len, struct virtio_trans *vtrans)
+{
+ struct virtio_mmio *vmmio = vtrans->virtio;
+ u32 val = 0;
+
+ switch(addr) {
+ case VIRTIO_MMIO_HOST_FEATURES_SEL:
+ case VIRTIO_MMIO_GUEST_FEATURES_SET:
+ case VIRTIO_MMIO_GUEST_PAGE_SIZE:
+ case VIRTIO_MMIO_QUEUE_SEL:
+ case VIRTIO_MMIO_QUEUE_NUM:
+ case VIRTIO_MMIO_QUEUE_ALIGN:
+ case VIRTIO_MMIO_STATUS:
+ *(u32 *)(((void *)&vmmio->hdr) + addr) = ioport__read32(data);
+ break;
+ case VIRTIO_MMIO_GUEST_FEATURES:
+ if (vmmio->hdr.guest_features_sel == 0) {
+ val = ioport__read32(data);
+ vtrans->virtio_ops->set_guest_features(vmmio->kvm, vmmio->dev, val);
+ }
+ break;
+ case VIRTIO_MMIO_QUEUE_PFN:
+ val = ioport__read32(data);
+ vtrans->virtio_ops->init_vq(vmmio->kvm, vmmio->dev, vmmio->hdr.queue_sel, val);
+ break;
+ case VIRTIO_MMIO_QUEUE_NOTIFY:
+ val = ioport__read32(data);
+ vtrans->virtio_ops->notify_vq(vmmio->kvm, vmmio->dev, val);
+ break;
+ case VIRTIO_MMIO_INTERRUPT_ACK:
+ val = ioport__read32(data);
+ vmmio->hdr.interrupt_state &= ~val;
+ break;
+ };
+}
+
+static void virtio_mmio__config_in(u64 addr, void *data, u32 len, struct virtio_trans *vtrans)
+{
+ struct virtio_mmio *vmmio = vtrans->virtio;
+ u32 val = 0;
+
+ switch(addr) {
+ case VIRTIO_MMIO_MAGIC_VALUE:
+ case VIRTIO_MMIO_DEVICE_ID:
+ case VIRTIO_MMIO_INTERRUPT_STATUS:
+ case VIRTIO_MMIO_STATUS:
+ case VIRTIO_MMIO_VENDOR_ID:
+ case VIRTIO_MMIO_VERSION:
+ ioport__write32(data, *(u32 *)(((void *)&vmmio->hdr) + addr));
+ break;
+ case VIRTIO_MMIO_HOST_FEATURES:
+ if (vmmio->hdr.host_features_sel == 0)
+ val = vtrans->virtio_ops->get_host_features(vmmio->kvm, vmmio->dev);
+ ioport__write32(data, val);
+ break;
+ case VIRTIO_MMIO_QUEUE_PFN:
+ val = vtrans->virtio_ops->get_pfn_vq(vmmio->kvm, vmmio->dev,
+ vmmio->hdr.queue_sel);
+ ioport__write32(data, val);
+ break;
+ case VIRTIO_MMIO_QUEUE_NUM_MAX:
+ val = vtrans->virtio_ops->get_size_vq(vmmio->kvm, vmmio->dev,
+ vmmio->hdr.queue_sel);
+ ioport__write32(data, val);
+ break;
+ }
+}
+
+static void callback_mmio(u64 addr, u8 *data, u32 len, u8 is_write, void *ptr)
+{
+ struct virtio_trans *vtrans = ptr;
+ struct virtio_mmio *vmmio = vtrans->virtio;
+ u32 offset = addr - vmmio->addr;
+
+ if (offset >= VIRTIO_MMIO_CONFIG) {
+ offset -= VIRTIO_MMIO_CONFIG;
+ virtio_mmio__device_specific(offset, data, len, is_write, ptr);
+ return;
+ }
+
+ if (is_write)
+ virtio_mmio__config_out(offset, data, len, ptr);
+ else
+ virtio_mmio__config_in(offset, data, len, ptr);
+}
+
+int virtio_mmio__init(struct kvm *kvm, struct virtio_trans *vtrans, void *dev,
+ int device_id, int subsys_id, int class)
+{
+ struct virtio_mmio *vmmio = vtrans->virtio;
+ u8 pin, ndev, line;
+
+ vmmio->dev = dev;
+ vmmio->addr = pci_get_io_space_block(PCI_IO_SIZE * 2);
+ vmmio->kvm = kvm;
+
+ kvm__register_mmio(kvm, vmmio->addr, PCI_IO_SIZE * 2, callback_mmio, vtrans);
+
+ vmmio->hdr = (struct virtio_mmio_hdr) {
+ .magic = {'v', 'i', 'r', 't'},
+ .version = 1,
+ .device_id = device_id - 0x1000 + 1,
+ .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
+ .queue_num_max = 256,
+ };
+
+ if (irq__register_device(subsys_id, &ndev, &pin, &line) < 0)
+ return -1;
+
+ pr_info("virtio-net assigned addr: %x - %x line: %d\n", vmmio->addr,
+ vmmio->addr + 0x200, line);
+ vmmio->irq = line;
+
+ return 0;
+}
diff --git a/tools/kvm/virtio/net.c b/tools/kvm/virtio/net.c
index cee2b5b..cfaab8c 100644
--- a/tools/kvm/virtio/net.c
+++ b/tools/kvm/virtio/net.c
@@ -26,7 +26,7 @@
#include <sys/types.h>
#include <sys/wait.h>
-#define VIRTIO_NET_QUEUE_SIZE 128
+#define VIRTIO_NET_QUEUE_SIZE 256
#define VIRTIO_NET_NUM_QUEUES 2
#define VIRTIO_NET_RX_QUEUE 0
#define VIRTIO_NET_TX_QUEUE 1
@@ -410,7 +410,11 @@ void virtio_net__init(const struct virtio_net_params *params)
ndev->ops = &uip_ops;
}
- virtio_trans_init(&ndev->vtrans, VIRTIO_PCI);
+ if (params->virtio_trans &&
+ strcmp(params->virtio_trans, "mmio") == 0)
+ virtio_trans_init(&ndev->vtrans, VIRTIO_MMIO);
+ else
+ virtio_trans_init(&ndev->vtrans, VIRTIO_PCI);
ndev->vtrans.trans_ops->init(kvm, &ndev->vtrans, ndev, PCI_DEVICE_ID_VIRTIO_NET,
VIRTIO_ID_NET, PCI_CLASS_NET);
ndev->vtrans.virtio_ops = &net_dev_virtio_ops;
diff --git a/tools/kvm/virtio/trans.c b/tools/kvm/virtio/trans.c
index 50c206d..60dbe88 100644
--- a/tools/kvm/virtio/trans.c
+++ b/tools/kvm/virtio/trans.c
@@ -1,6 +1,7 @@
#include "kvm/virtio-trans.h"
#include "kvm/virtio-pci.h"
+#include "kvm/virtio-mmio.h"
#include "kvm/util.h"
#include <stdlib.h>
@@ -16,7 +17,17 @@ int virtio_trans_init(struct virtio_trans *vtrans, enum virtio_trans_type type)
die("Failed allocating virtio transport");
vtrans->virtio = trans;
vtrans->trans_ops = virtio_pci__get_trans_ops();
+ break;
+ case VIRTIO_MMIO:
+ trans = calloc(sizeof(struct virtio_mmio), 1);
+ if (!trans)
+ die("Failed allocating virtio transport");
+ vtrans->virtio = trans;
+ vtrans->trans_ops = virtio_mmio__get_trans_ops();
+ break;
default:
return -1;
};
+
+ return 0;
}
\ No newline at end of file
--
1.7.8.rc1
^ permalink raw reply related
* Re: [RFC] kvm tools: Add support for virtio-mmio
From: Peter Maydell @ 2011-11-15 17:00 UTC (permalink / raw)
To: Sasha Levin
Cc: gorcunov, kvm, Pawel Moll, asias.hejun, virtualization, penberg,
mingo
In-Reply-To: <1321375667-17284-1-git-send-email-levinsasha928@gmail.com>
On 15 November 2011 16:47, Sasha Levin <levinsasha928@gmail.com> wrote:
> + vmmio->hdr = (struct virtio_mmio_hdr) {
> + .magic = {'v', 'i', 'r', 't'},
> + .version = 1,
> + .device_id = device_id - 0x1000 + 1,
> + .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
> + .queue_num_max = 256,
> + };
This isn't a PCI device, so does it make sense to use a PCI vendor
ID here? The kernel doesn't check the vendor ID at the moment,
but presumably the idea of the field is to allow the kernel to
work around implementation bugs/blacklist/whatever if necessary.
If that's the theory then it would make more sense for QEMU and
kvm-tool to use IDs that say "this is the QEMU implementation"
and "this is the kvm-tool implementation".
(I picked 0x554D4551 for QEMU...)
-- PMM
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] kvm tools: Add support for virtio-mmio
From: Sasha Levin @ 2011-11-15 17:56 UTC (permalink / raw)
To: Peter Maydell
Cc: gorcunov, kvm, Pawel Moll, asias.hejun, virtualization, penberg,
mingo
In-Reply-To: <CAFEAcA-2QGk_Y1R_FPrVRVGiP7KyQOuv0zubORm77cOoU_K6gQ@mail.gmail.com>
On Tue, 2011-11-15 at 17:00 +0000, Peter Maydell wrote:
> On 15 November 2011 16:47, Sasha Levin <levinsasha928@gmail.com> wrote:
> > + vmmio->hdr = (struct virtio_mmio_hdr) {
> > + .magic = {'v', 'i', 'r', 't'},
> > + .version = 1,
> > + .device_id = device_id - 0x1000 + 1,
> > + .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
> > + .queue_num_max = 256,
> > + };
>
> This isn't a PCI device, so does it make sense to use a PCI vendor
> ID here? The kernel doesn't check the vendor ID at the moment,
> but presumably the idea of the field is to allow the kernel to
> work around implementation bugs/blacklist/whatever if necessary.
> If that's the theory then it would make more sense for QEMU and
> kvm-tool to use IDs that say "this is the QEMU implementation"
> and "this is the kvm-tool implementation".
>
> (I picked 0x554D4551 for QEMU...)
>
> -- PMM
I just sheepishly filled in the only vendor ID I knew of in the virtio
spec :)
Hmm... If thats the plan, it should probably be a virtio thing (not
virtio-mmio specific).
Either way, it could also use some clarification in the spec.
--
Sasha.
^ permalink raw reply
* Re: [RFC] kvm tools: Add support for virtio-mmio
From: Sasha Levin @ 2011-11-15 18:13 UTC (permalink / raw)
To: Avi Kivity
Cc: Peter Maydell, Pawel Moll, kvm, asias.hejun, virtualization,
penberg, gorcunov, mingo
In-Reply-To: <4EC2ABEC.1040007@redhat.com>
On Tue, 2011-11-15 at 20:14 +0200, Avi Kivity wrote:
> On 11/15/2011 07:56 PM, Sasha Levin wrote:
> > >
> > > This isn't a PCI device, so does it make sense to use a PCI vendor
> > > ID here? The kernel doesn't check the vendor ID at the moment,
> > > but presumably the idea of the field is to allow the kernel to
> > > work around implementation bugs/blacklist/whatever if necessary.
> > > If that's the theory then it would make more sense for QEMU and
> > > kvm-tool to use IDs that say "this is the QEMU implementation"
> > > and "this is the kvm-tool implementation".
> > >
> > > (I picked 0x554D4551 for QEMU...)
> > >
> > > -- PMM
> >
> > I just sheepishly filled in the only vendor ID I knew of in the virtio
> > spec :)
> >
> > Hmm... If thats the plan, it should probably be a virtio thing (not
> > virtio-mmio specific).
> >
> > Either way, it could also use some clarification in the spec.
>
> The spec only covers virtio-pci; this virtio-mmio is completely
> unspec'ed. IMO it's a timebomb waiting to explode.
It is, look at Appendix X of the virtio-pci spec.
--
Sasha.
^ permalink raw reply
* Re: [RFC] kvm tools: Add support for virtio-mmio
From: Avi Kivity @ 2011-11-15 18:14 UTC (permalink / raw)
To: Sasha Levin
Cc: Peter Maydell, Pawel Moll, kvm, asias.hejun, virtualization,
penberg, gorcunov, mingo
In-Reply-To: <1321379773.3200.9.camel@lappy>
On 11/15/2011 07:56 PM, Sasha Levin wrote:
> >
> > This isn't a PCI device, so does it make sense to use a PCI vendor
> > ID here? The kernel doesn't check the vendor ID at the moment,
> > but presumably the idea of the field is to allow the kernel to
> > work around implementation bugs/blacklist/whatever if necessary.
> > If that's the theory then it would make more sense for QEMU and
> > kvm-tool to use IDs that say "this is the QEMU implementation"
> > and "this is the kvm-tool implementation".
> >
> > (I picked 0x554D4551 for QEMU...)
> >
> > -- PMM
>
> I just sheepishly filled in the only vendor ID I knew of in the virtio
> spec :)
>
> Hmm... If thats the plan, it should probably be a virtio thing (not
> virtio-mmio specific).
>
> Either way, it could also use some clarification in the spec.
The spec only covers virtio-pci; this virtio-mmio is completely
unspec'ed. IMO it's a timebomb waiting to explode.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC] kvm tools: Add support for virtio-mmio
From: Avi Kivity @ 2011-11-15 18:18 UTC (permalink / raw)
To: Sasha Levin
Cc: Peter Maydell, Pawel Moll, kvm, asias.hejun, virtualization,
penberg, gorcunov, mingo
In-Reply-To: <1321380834.3200.10.camel@lappy>
On 11/15/2011 08:13 PM, Sasha Levin wrote:
> > >
> > > Hmm... If thats the plan, it should probably be a virtio thing (not
> > > virtio-mmio specific).
> > >
> > > Either way, it could also use some clarification in the spec.
> >
> > The spec only covers virtio-pci; this virtio-mmio is completely
> > unspec'ed. IMO it's a timebomb waiting to explode.
>
> It is, look at Appendix X of the virtio-pci spec.
>
Ah, okay, a pleasant surprise. From a quick look, it seems okay, but I
think endianness specification is missing.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC] kvm tools: Add support for virtio-mmio
From: Sasha Levin @ 2011-11-15 18:22 UTC (permalink / raw)
To: Avi Kivity
Cc: Peter Maydell, Pawel Moll, kvm, asias.hejun, virtualization,
penberg, gorcunov, mingo
In-Reply-To: <4EC2AD09.2040000@redhat.com>
On Tue, 2011-11-15 at 20:18 +0200, Avi Kivity wrote:
> On 11/15/2011 08:13 PM, Sasha Levin wrote:
> > > >
> > > > Hmm... If thats the plan, it should probably be a virtio thing (not
> > > > virtio-mmio specific).
> > > >
> > > > Either way, it could also use some clarification in the spec.
> > >
> > > The spec only covers virtio-pci; this virtio-mmio is completely
> > > unspec'ed. IMO it's a timebomb waiting to explode.
> >
> > It is, look at Appendix X of the virtio-pci spec.
> >
>
> Ah, okay, a pleasant surprise. From a quick look, it seems okay, but I
> think endianness specification is missing.
Endianness is defined there simply as "The endianness of the registers
follows the native endianness of the Guest.", similarly to the
virtio-pci spec.
--
Sasha.
^ permalink raw reply
* Re: [PATCHv2 RFC] virtio-spec: flexible configuration layout
From: Rusty Russell @ 2011-11-15 23:58 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, kvm, Pawel Moll, Wang Sheng-Hui,
Alexey Kardashevskiy, lkml - Kernel Mailing List, virtualization,
penberg, Christian Borntraeger, Sasha Levin, Amit Shah, avi
In-Reply-To: <20111113151427.GA16749@redhat.com>
On Sun, 13 Nov 2011 17:14:27 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Nov 11, 2011 at 02:54:31PM +1030, Rusty Russell wrote:
> > Indeed, I'd like to see two changes to your proposal:
> >
> > (1) It should be all or nothing. If a driver can find the virtio header
> > capability, it should only use the capabilties. Otherwise, it
> > should fall back to legacy.
>
> Okay, but going forward, if we add more capabilities, we probably won't
> want to require them and fail to load if not there. That's really why I
> wanted to make the failover ignore any capability separately - to make
> this future proof. I'm not terribly fixated on this, it just seemed a
> bit more symmetrical to treat all capabilities in the same way. Hmm?
Sure, a future capbility may not exist. But once a driver finds that
virtio header structure in the capability, it should *never* fall back
to the legacy area. ie. it can expect that Queue Notify, ISR Status and
Device Header all exist.
ie. either use legacy mode, or use capabilities. Never both.
>
> > Your draft suggests a mix is possible;
> > I prefer a clean failure (ie. one day don't present a BAR 0 *at
> > all*, so ancient drivers just fail to load.).
>
> Just to clarify, as written in draft this is possible with the current
> spec proposal. So I'm guessing there's some other motivation that you
> had in mind?
At the moment you give a hybrid model where both are used. In five
years' time, that's going to be particularly ugly.
>
> > (2) There's no huge win in keeping the same layout. Let's make some
> > cleanups.
>
> About this last point - what cleanups do you have in mind? Just move
> some registers around? I guess we could put feature bits near each
> other, and move device status towards the end to avoid wasting 3
> bytes.
> The win seems minimal, but the change does make legacy hypervisor
> support in guests more cumbersome, as we need to spread coditional code
> around instead of localizing it in the initialization path.
But the separation between "legacy" and "modern" will be sharper, making
it easier to excise the legacy portion later.
And in five years' time, people implementing virtio will really thank us
that they can completely ignore the legacy header.
> > There are more users ahead of us then behind us (I
> > hope!).
>
> In that case isn't it safe to assume we'll find some uses
> for the reserved registers?
How would we tell? If we use a new capability struct for it, it's
obvious. Otherwise, you're going to need to steal more feature bits.
Cheers,
Rusty.
PS. Sorry, was off sick for a few days.
^ permalink raw reply
* Re: [PATCHv2 RFC] virtio-spec: flexible configuration layout
From: Rusty Russell @ 2011-11-15 23:58 UTC (permalink / raw)
To: Sasha Levin
Cc: Krishna Kumar, kvm, Pawel Moll, Michael S. Tsirkin,
Alexey Kardashevskiy, Wang Sheng-Hui, lkml - Kernel Mailing List,
virtualization, penberg, Christian Borntraeger, avi, Amit Shah
In-Reply-To: <CA+1xoqeH3ErNCELD+NoJHz=eH6FtxersUffoJSj0yQx2o=4g0g@mail.gmail.com>
On Fri, 11 Nov 2011 09:39:13 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 6:24 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > (2) There's no huge win in keeping the same layout. Let's make some
> > cleanups. There are more users ahead of us then behind us (I
> > hope!).
>
> Actually, if we already do cleanups, here are two more suggestions:
>
> 1. Make 64bit features a one big 64bit block, instead of having 32bits
> in one place and 32 in another.
> 2. Remove the reserved fields out of the config (the ones that were
> caused by moving the ISR and the notifications out).
Yes, those were exactly what I was thinking. I left it vague because
there might be others you can see if we're prepared to abandon the
current format.
Cheers,
Rusty.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] kvm tools: Implement multiple VQ for virtio-net
From: Rusty Russell @ 2011-11-16 0:04 UTC (permalink / raw)
To: Michael S. Tsirkin, Pekka Enberg
Cc: Krishna Kumar, kvm, Asias He, virtualization, gorcunov,
Sasha Levin, netdev, mingo, Stephen Hemminger
In-Reply-To: <20111114130507.GA18288@redhat.com>
On Mon, 14 Nov 2011 15:05:07 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Nov 14, 2011 at 02:25:17PM +0200, Pekka Enberg wrote:
> > On Mon, Nov 14, 2011 at 4:04 AM, Asias He <asias.hejun@gmail.com> wrote:
> > > Why both the bandwidth and latency performance are dropping so dramatically
> > > with multiple VQ?
> >
> > What's the expected benefit from multiple VQs
>
> Heh, the original patchset didn't mention this :) It really should.
> They are supposed to speed up networking for high smp guests.
If we have one queue per guest CPU, does this allow us to run lockless?
Thanks,
Rusty.
^ permalink raw reply
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