Re: Paravirtualization on VMware's Platform [VMI].
On Thu, 2009-10-01 at 20:00 -0700, Eric W. Biederman wrote: > >> btw the "default" in KConfig tends to be totally ignored by distro > >> kernel maintainers... please don't assume that just because some default > >> is set in KConfig it has ANY impact on what shows up in distributions. > > > > So, are you saying that we should be doing something else along with > > toggling it off in the Kconfig ? > > We have already informed most of the distro folks about this deprecation > > so I think we should be okay there, but if there is something else that > > should be done, do let me know. > > Perhaps log a message when it is first used? Yeah, Chris' suggestion about adding "deprecated" string in pv_info.name does just that. Thanks, Alok ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: Paravirtualization on VMware's Platform [VMI].
Alok Kataria writes: > On Tue, 2009-09-29 at 01:08 -0700, Arjan van de Ven wrote: >> > For now I have just added some text in the feature-removal file and >> > disabled VMI by default in the Kconfig, the reason that needs to be >> > done is because "Live Migration" of a VMI enabled VM to future >> > products which don't support VMI will not work, so its important that >> > newer distros keep this disabled, if they want seamless migration >> > that is. >> >> btw the "default" in KConfig tends to be totally ignored by distro >> kernel maintainers... please don't assume that just because some default >> is set in KConfig it has ANY impact on what shows up in distributions. > > So, are you saying that we should be doing something else along with > toggling it off in the Kconfig ? > We have already informed most of the distro folks about this deprecation > so I think we should be okay there, but if there is something else that > should be done, do let me know. Perhaps log a message when it is first used? I do that for sysctl right now. Eric ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 2.6.32-rc1] net: VMware virtual Ethernet NIC driver: vmxnet3
From: Shreyas Bhatewara
Date: Wed, 30 Sep 2009 14:34:57 -0700 (PDT)
> +{
> + struct vmxnet3_adapter *adapter = netdev_priv(netdev);
> + u8 *base;
> + int i;
> +
> + VMXNET3_WRITE_BAR1_REG(adapter, VMXNET3_REG_CMD,
> VMXNET3_CMD_GET_STATS);
> +
> + /* this does assume each counter is 64-bit wide */
> +
> + base = (u8 *)&adapter->tqd_start->stats;
> + for (i = 0; i < ARRAY_SIZE(vmxnet3_tq_dev_stats); i++)
> + *buf++ = *(u64 *)(base + vmxnet3_tq_dev_stats[i].offset);
> +
> + base = (u8 *)&adapter->tx_queue.stats;
> + for (i = 0; i < ARRAY_SIZE(vmxnet3_tq_driver_stats); i++)
> + *buf++ = *(u64 *)(base + vmxnet3_tq_driver_stats[i].offset);
> +
> + base = (u8 *)&adapter->rqd_start->stats;
There's a lot of code like this that isn't indented properly. Either
that or your email client has corrupted the patch by breaking up long
lines or similar.
Another example:
> +static int
> +vmxnet3_set_rx_csum(struct net_device *netdev, u32 val)
> +{
> + struct vmxnet3_adapter *adapter = netdev_priv(netdev);
> +
> + if (adapter->rxcsum != val) {
> + adapter->rxcsum = val;
> + if (netif_running(netdev)) {
> + if (val)
> + adapter->shared->devRead.misc.uptFeatures |=
> + UPT1_F_RXCSUM;
> + else
> + adapter->shared->devRead.misc.uptFeatures &=
> + ~UPT1_F_RXCSUM;
> +
> + VMXNET3_WRITE_BAR1_REG(adapter, VMXNET3_REG_CMD,
> + VMXNET3_CMD_UPDATE_FEATURE);
> + }
> + }
> + return 0;
> +}
Yikes! :-)
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: INFO: task kjournal:337 blocked for more than 120 seconds
Switching to different scheduler doesn't make the problem gone away. Shirley ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: INFO: task kjournal:337 blocked for more than 120 seconds
On Thu, 2009-10-01 at 16:03 -0500, Javier Guerra wrote: > deadline is the most recommended one for virtualization hosts. some > distros set it as default if you select Xen or KVM at installation > time. (and noop for the guests) I spoke too earlier, after a while noop scheduler hit the same issue. I am switching to deadline to test it again. Thanks Shirley ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: INFO: task kjournal:337 blocked for more than 120 seconds
On Thu, Oct 1, 2009 at 4:00 PM, Shirley Ma wrote: > I talked to Mingming, she suggested to use different IO scheduler. The > default scheduler is cfg, after I switch to noop, the problem is gone. deadline is the most recommended one for virtualization hosts. some distros set it as default if you select Xen or KVM at installation time. (and noop for the guests) -- Javier ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: INFO: task kjournal:337 blocked for more than 120 seconds
I talked to Mingming, she suggested to use different IO scheduler. The default scheduler is cfg, after I switch to noop, the problem is gone. So there seems a bug in cfg scheduler. It's easily reproduced it when running the guest kernel, so far I haven't hit this problem on the host side. If I need to file a bug for some one to look at, please let me know. Thanks Shirley ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
Avi Kivity wrote: > On 09/30/2009 10:04 PM, Gregory Haskins wrote: > > >>> A 2.6.27 guest, or Windows guest with the existing virtio drivers, >>> won't work >>> over vbus. >>> >> Binary compatibility with existing virtio drivers, while nice to have, >> is not a specific requirement nor goal. We will simply load an updated >> KMP/MSI into those guests and they will work again. As previously >> discussed, this is how more or less any system works today. It's like >> we are removing an old adapter card and adding a new one to "uprev the >> silicon". >> > > Virtualization is about not doing that. Sometimes it's necessary (when > you have made unfixable design mistakes), but just to replace a bus, > with no advantages to the guest that has to be changed (other > hypervisors or hypervisorless deployment scenarios aren't). The problem is that your continued assertion that there is no advantage to the guest is a completely unsubstantiated claim. As it stands right now, I have a public git tree that, to my knowledge, is the fastest KVM PV networking implementation around. It also has capabilities that are demonstrably not found elsewhere, such as the ability to render generic shared-memory interconnects (scheduling, timers), interrupt-priority (qos), and interrupt-coalescing (exit-ratio reduction). I designed each of these capabilities after carefully analyzing where KVM was coming up short. Those are facts. I can't easily prove which of my new features alone are what makes it special per se, because I don't have unit tests for each part that breaks it down. What I _can_ state is that its the fastest and most feature rich KVM-PV tree that I am aware of, and others may download and test it themselves to verify my claims. The disproof, on the other hand, would be in a counter example that still meets all the performance and feature criteria under all the same conditions while maintaining the existing ABI. To my knowledge, this doesn't exist. Therefore, if you believe my work is irrelevant, show me a git tree that accomplishes the same feats in a binary compatible way, and I'll rethink my position. Until then, complaining about lack of binary compatibility is pointless since it is not an insurmountable proposition, and the one and only available solution declares it a required casualty. > >>> Further, non-shmem virtio can't work over vbus. >>> >> Actually I misspoke earlier when I said virtio works over non-shmem. >> Thinking about it some more, both virtio and vbus fundamentally require >> shared-memory, since sharing their metadata concurrently on both sides >> is their raison d'être. >> >> The difference is that virtio utilizes a pre-translation/mapping (via >> ->add_buf) from the guest side. OTOH, vbus uses a post translation >> scheme (via memctx) from the host-side. If anything, vbus is actually >> more flexible because it doesn't assume the entire guest address space >> is directly mappable. >> >> In summary, your statement is incorrect (though it is my fault for >> putting that idea in your head). >> > > Well, Xen requires pre-translation (since the guest has to give the host > (which is just another guest) permissions to access the data). Actually I am not sure that it does require pre-translation. You might be able to use the memctx->copy_to/copy_from scheme in post translation as well, since those would be able to communicate to something like the xen kernel. But I suppose either method would result in extra exits, so there is no distinct benefit using vbus there..as you say below "they're just different". The biggest difference is that my proposed model gets around the notion that the entire guest address space can be represented by an arbitrary pointer. For instance, the copy_to/copy_from routines take a GPA, but may use something indirect like a DMA controller to access that GPA. On the other hand, virtio fully expects a viable pointer to come out of the interface iiuc. This is in part what makes vbus more adaptable to non-virt. > So neither is a superset of the other, they're just different. > > It doesn't really matter since Xen is unlikely to adopt virtio. Agreed. > >> An interesting thing here is that you don't even need a fancy >> multi-homed setup to see the effects of my exit-ratio reduction work: >> even single port configurations suffer from the phenomenon since many >> devices have multiple signal-flows (e.g. network adapters tend to have >> at least 3 flows: rx-ready, tx-complete, and control-events (link-state, >> etc). Whats worse, is that the flows often are indirectly related (for >> instance, many host adapters will free tx skbs during rx operations, so >> you tend to get bursts of tx-completes at the same time as rx-ready. If >> the flows map 1:1 with IDT, they will suffer the same problem. >> > > You can simply use the same vector for both rx and tx and poll both at > every interrupt. Yes, but that has its own problems: e.
Re: INFO: task journal:337 blocked for more than 120 seconds
On Thu, 2009-10-01 at 10:20 -0300, Marcelo Tosatti wrote: > I've hit this in the past with ext3, mounting with data=writeback made > it > disappear. Thanks. I will make a try. Someone should fix this. Shirley ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
On (Thu) Oct 01 2009 [14:04:37], Christian Borntraeger wrote: > Am Donnerstag 01 Oktober 2009 13:58:01 schrieben Sie: > > I spawned two ports; one doing 'find /' and the other transferring a > > 800M file from the host to the guest, both running at the same time. > > This is on top of the latest Linus tree + my patches. It works fine. > > > > Can you give me any additional info that can help me nail this down? > > This is just a wild guess: My guest has 8 cpus and virtio requires that users > do > a proper locking. But as far as I see you use schedule_work which should be > single threaded. > Or maybe this is an existing bug that is just exposed by your patch - dont > know. I think there might be two bugs. One is the readbuf_head list needs some locks around its operations. The readbuf_head list is a per-port list where buffers received from the host for a port are stored. They're taken off that list when userspace issues read() requests. The other bug is the virtio one that you saw. I'll try to see how that one gets triggered. Thanks, Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: INFO: task journal:337 blocked for more than 120 seconds
On Wed, Sep 30, 2009 at 02:11:52PM -0700, Shirley Ma wrote: > Hello all, > > Anybody found this problem before? I kept hitting this issue for 2.6.31 > guest kernel even with a simple network test. > > INFO: task kjournal:337 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_sec" disables this message. > > kjournald D 0041 0 337 2 0x > > My test is totally being blocked. I've hit this in the past with ext3, mounting with data=writeback made it disappear. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
Am Donnerstag 01 Oktober 2009 13:58:01 schrieben Sie: > I spawned two ports; one doing 'find /' and the other transferring a > 800M file from the host to the guest, both running at the same time. > This is on top of the latest Linus tree + my patches. It works fine. > > Can you give me any additional info that can help me nail this down? This is just a wild guess: My guest has 8 cpus and virtio requires that users do a proper locking. But as far as I see you use schedule_work which should be single threaded. Or maybe this is an existing bug that is just exposed by your patch - dont know. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
On (Thu) Oct 01 2009 [12:28:30], Christian Borntraeger wrote: > Am Mittwoch 30 September 2009 19:13:21 schrieben Sie: > > On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote: > > > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah: > > > > Great, thanks. However I was thinking of moving this init to the > > > > probe() routine instead of in the init_conosle routine just because > > > > multiple consoles can be added and we don't want to init this each > > > > time.. just once in probe is fine. > > > > > > If you have new patch CC me and I can give it a spin. > > > > Hey Christian, > > > > I have a new patch that changes a few things: > > - moves the put_char fix to probe instead of doing it in > > init_port_console(), which gets called on each console port found. > > - uses port->id instead of a static hvc_vtermno to pass on a value to > > hvc_alloc(). Motivation explained within comments in the code. > > - A few other changes that introduce and make use of port->vcon instead > > of accessing the static virtconsole directly -- aimed at easing future > > fix to have multiple virtio-console devices. > > > > It would be great if you could test this. > > With the latest git kernel + your patch I sometmes get a completely frozen > console. In the dump there is > > <3>virtio_console virtio0: output:id 68 is not a head! > > Seems that I can reproduce it with large amounts of output (find / for > example) > Without your patch everything is fine. I spawned two ports; one doing 'find /' and the other transferring a 800M file from the host to the guest, both running at the same time. This is on top of the latest Linus tree + my patches. It works fine. Can you give me any additional info that can help me nail this down? Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
On (Thu) Oct 01 2009 [12:28:30], Christian Borntraeger wrote: > Am Mittwoch 30 September 2009 19:13:21 schrieben Sie: > > On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote: > > > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah: > > > > Great, thanks. However I was thinking of moving this init to the > > > > probe() routine instead of in the init_conosle routine just because > > > > multiple consoles can be added and we don't want to init this each > > > > time.. just once in probe is fine. > > > > > > If you have new patch CC me and I can give it a spin. > > > > Hey Christian, > > > > I have a new patch that changes a few things: > > - moves the put_char fix to probe instead of doing it in > > init_port_console(), which gets called on each console port found. > > - uses port->id instead of a static hvc_vtermno to pass on a value to > > hvc_alloc(). Motivation explained within comments in the code. > > - A few other changes that introduce and make use of port->vcon instead > > of accessing the static virtconsole directly -- aimed at easing future > > fix to have multiple virtio-console devices. > > > > It would be great if you could test this. > > With the latest git kernel + your patch I sometmes get a completely frozen > console. In the dump there is > > <3>virtio_console virtio0: output:id 68 is not a head! > > Seems that I can reproduce it with large amounts of output (find / for > example) > Without your patch everything is fine. Do you mean the entire patch? Or just the last snippet that I sent? I'm testing things using a few days old linux-next; I guess you're seeing this with Linus' git tree? I'll try that. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
Am Mittwoch 30 September 2009 19:13:21 schrieben Sie: > On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote: > > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah: > > > Great, thanks. However I was thinking of moving this init to the > > > probe() routine instead of in the init_conosle routine just because > > > multiple consoles can be added and we don't want to init this each > > > time.. just once in probe is fine. > > > > If you have new patch CC me and I can give it a spin. > > Hey Christian, > > I have a new patch that changes a few things: > - moves the put_char fix to probe instead of doing it in > init_port_console(), which gets called on each console port found. > - uses port->id instead of a static hvc_vtermno to pass on a value to > hvc_alloc(). Motivation explained within comments in the code. > - A few other changes that introduce and make use of port->vcon instead > of accessing the static virtconsole directly -- aimed at easing future > fix to have multiple virtio-console devices. > > It would be great if you could test this. With the latest git kernel + your patch I sometmes get a completely frozen console. In the dump there is <3>virtio_console virtio0: output:id 68 is not a head! Seems that I can reproduce it with large amounts of output (find / for example) Without your patch everything is fine. Christian ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
On (Thu) Oct 01 2009 [11:00:48], Christian Borntraeger wrote:
> Am Mittwoch 30 September 2009 19:13:21 schrieb Amit Shah:
> > - uses port->id instead of a static hvc_vtermno to pass on a value to
> > hvc_alloc(). Motivation explained within comments in the code.
>
> [...]
> > +* The first argument of hvc_alloc() is the virtual console
> > +* number. hvc_alloc() checks if a console with the same value
> > +* was used in hvc_instantiate(). We may not end up passing
> > +* the same value here (we use the value 0 in
> > +* hvc_instantiate() but the console port may not be at id
> > +* 0). This isn't a problem, though. Nothing in hvc really
> > +* depends on these numbers and since this number is passed on
> > +* to us when cons_get/put_chars() is called, it's preferable
> > +* to pass on the port->id so that we can get the port struct
> > +* via get_port_from_id().
> [...]
> > + port->hvc = hvc_alloc(port->id, 0, &virtio_cons, PAGE_SIZE);
>
> I am not sure if this is going to be ok.
>
> When I change the old code (without your patch) to use vtermno=0 in
> hvc_instantiate and vtermno=1 in hvc_alloc I get
> "Warning: unable to open an initial console."
>
> It seems to me that we have to pass the same values.
OK; that's bad enough. The following diff reverts that patch and adds a
new get_port_from_vtermno() that works from hvc callbacks.
What do you think? (Applies on top of the latest patch I sent.)
Amit
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index b2de2df..a8ba5aa 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -105,12 +105,42 @@ struct virtio_console_port {
/* The 'id' to identify the port with the Host */
u32 id;
+ /*
+* If this port is a console port, this number identifies the
+* number that we used to register with hvc in
+* hvc_instantiate() and hvc_alloc().
+*/
+ u32 vtermno;
+
/* Is the host device open */
bool host_connected;
};
static struct virtio_console_struct virtconsole;
+/*
+ * This is used to keep track of the number of hvc consoles spawned.
+ * This number is given as first argument to hvc_alloc(). We could as
+ * well pass on the minor number of the char device but to correctly
+ * map an initial console spawned via hvc_instantiate to the console
+ * being hooked up via hvc_alloc, we need to pass the same vtermno.
+ *
+ * With this int, we just assume the first console being initialised
+ * was the first one that got used as the initial console.
+ */
+static unsigned int hvc_vtermno;
+
+static struct virtio_console_port *get_port_from_vtermno(u32 vtermno)
+{
+ struct virtio_console_port *port;
+
+ list_for_each_entry(port, &virtconsole.port_head, next) {
+ if (port->vtermno == vtermno)
+ return port;
+ }
+ return NULL;
+}
+
static struct virtio_console_port *get_port_from_devt(dev_t devt)
{
struct virtio_console_port *port;
@@ -457,7 +487,7 @@ static int cons_put_chars(u32 vtermno, const char *buf, int
count)
{
struct virtio_console_port *port;
- port = get_port_from_id(vtermno);
+ port = get_port_from_vtermno(vtermno);
if (!port)
return 0;
@@ -478,7 +508,7 @@ static int cons_get_chars(u32 vtermno, char *buf, int count)
/* If we don't have an input queue yet, we can't get input. */
BUG_ON(!virtconsole.in_vq);
- port = get_port_from_id(vtermno);
+ port = get_port_from_vtermno(vtermno);
if (!port)
return 0;
@@ -566,32 +596,23 @@ int init_port_console(struct virtio_console_port *port)
* hvc_alloc().
*
* The first argument of hvc_alloc() is the virtual console
-* number. hvc_alloc() checks if a console with the same value
-* was used in hvc_instantiate(). We may not end up passing
-* the same value here (we use the value 0 in
-* hvc_instantiate() but the console port may not be at id
-* 0). This isn't a problem, though. Nothing in hvc really
-* depends on these numbers and since this number is passed on
-* to us when cons_get/put_chars() is called, it's preferable
-* to pass on the port->id so that we can get the port struct
-* via get_port_from_id().
-*
-* The second argument is the parameter for the notification
-* mechanism (like irq number). We currently leave this as
-* zero, virtqueues have implicit notifications.
+* number. The second argument is the parameter for the
+* notification mechanism (like irq number). We currently
+* leave this as zero, virtqueues have implicit notifications.
*
* The third argument is a "struct hv_ops" containing the
* put_chars() get_chars(), notifier_add() and notifier_del()
*
Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
On Thu, Oct 01, 2009 at 10:34:17AM +0200, Avi Kivity wrote: >> Second, I do not use ioeventfd anymore because it has too many problems >> with the surrounding technology. However, that is a topic for a >> different thread. >> > > Please post your issues. I see ioeventfd/irqfd as critical kvm interfaces. I second that. AFAIK ioeventfd/irqfd got exposed to userspace in 2.6.32-rc1, if there are issues we better nail them before 2.6.32 is out. And yes, please start a different thread. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
Am Mittwoch 30 September 2009 19:13:21 schrieb Amit Shah: > - uses port->id instead of a static hvc_vtermno to pass on a value to > hvc_alloc(). Motivation explained within comments in the code. [...] > + * The first argument of hvc_alloc() is the virtual console > + * number. hvc_alloc() checks if a console with the same value > + * was used in hvc_instantiate(). We may not end up passing > + * the same value here (we use the value 0 in > + * hvc_instantiate() but the console port may not be at id > + * 0). This isn't a problem, though. Nothing in hvc really > + * depends on these numbers and since this number is passed on > + * to us when cons_get/put_chars() is called, it's preferable > + * to pass on the port->id so that we can get the port struct > + * via get_port_from_id(). [...] > + port->hvc = hvc_alloc(port->id, 0, &virtio_cons, PAGE_SIZE); I am not sure if this is going to be ok. When I change the old code (without your patch) to use vtermno=0 in hvc_instantiate and vtermno=1 in hvc_alloc I get "Warning: unable to open an initial console." It seems to me that we have to pass the same values. Christian ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
Am Donnerstag 01 Oktober 2009 10:47:37 schrieb Amit Shah: > > > It would be great if you could test this. > > > > The basic stuff seems to work, but when I did a console resize I get: > > ... > > > One of the config->get() related changes is probably wrong. > > I see it. The following should fix it. Yes, it does. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
On (Thu) Oct 01 2009 [10:17:29], Christian Borntraeger wrote:
> Am Mittwoch 30 September 2009 19:13:21 schrieb Amit Shah:
> > On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote:
> > > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah:
> > > > Great, thanks. However I was thinking of moving this init to the
> > > > probe() routine instead of in the init_conosle routine just because
> > > > multiple consoles can be added and we don't want to init this each
> > > > time.. just once in probe is fine.
> > >
> > > If you have new patch CC me and I can give it a spin.
> >
> > Hey Christian,
> >
> > I have a new patch that changes a few things:
> > - moves the put_char fix to probe instead of doing it in
> > init_port_console(), which gets called on each console port found.
> > - uses port->id instead of a static hvc_vtermno to pass on a value to
> > hvc_alloc(). Motivation explained within comments in the code.
> > - A few other changes that introduce and make use of port->vcon instead
> > of accessing the static virtconsole directly -- aimed at easing future
> > fix to have multiple virtio-console devices.
> >
> > It would be great if you could test this.
>
> The basic stuff seems to work, but when I did a console resize I get:
...
> One of the config->get() related changes is probably wrong.
I see it. The following should fix it.
Amit
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 30361c1..b2de2df 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -822,9 +822,10 @@ static void tx_intr(struct virtqueue *vq)
static void config_intr(struct virtio_device *vdev)
{
- /* Handle port hot-add */
- schedule_work(&virtconsole.config_work);
-
+ if (use_multiport()) {
+ /* Handle port hot-add */
+ schedule_work(&virtconsole.config_work);
+ }
/* Handle console size changes */
virtcons_apply_config(vdev);
}
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
On 09/30/2009 10:04 PM, Gregory Haskins wrote: >> A 2.6.27 guest, or Windows guest with the existing virtio drivers, won't work >> over vbus. >> > Binary compatibility with existing virtio drivers, while nice to have, > is not a specific requirement nor goal. We will simply load an updated > KMP/MSI into those guests and they will work again. As previously > discussed, this is how more or less any system works today. It's like > we are removing an old adapter card and adding a new one to "uprev the > silicon". > Virtualization is about not doing that. Sometimes it's necessary (when you have made unfixable design mistakes), but just to replace a bus, with no advantages to the guest that has to be changed (other hypervisors or hypervisorless deployment scenarios aren't). >> Further, non-shmem virtio can't work over vbus. >> > Actually I misspoke earlier when I said virtio works over non-shmem. > Thinking about it some more, both virtio and vbus fundamentally require > shared-memory, since sharing their metadata concurrently on both sides > is their raison d'être. > > The difference is that virtio utilizes a pre-translation/mapping (via > ->add_buf) from the guest side. OTOH, vbus uses a post translation > scheme (via memctx) from the host-side. If anything, vbus is actually > more flexible because it doesn't assume the entire guest address space > is directly mappable. > > In summary, your statement is incorrect (though it is my fault for > putting that idea in your head). > Well, Xen requires pre-translation (since the guest has to give the host (which is just another guest) permissions to access the data). So neither is a superset of the other, they're just different. It doesn't really matter since Xen is unlikely to adopt virtio. > An interesting thing here is that you don't even need a fancy > multi-homed setup to see the effects of my exit-ratio reduction work: > even single port configurations suffer from the phenomenon since many > devices have multiple signal-flows (e.g. network adapters tend to have > at least 3 flows: rx-ready, tx-complete, and control-events (link-state, > etc). Whats worse, is that the flows often are indirectly related (for > instance, many host adapters will free tx skbs during rx operations, so > you tend to get bursts of tx-completes at the same time as rx-ready. If > the flows map 1:1 with IDT, they will suffer the same problem. > You can simply use the same vector for both rx and tx and poll both at every interrupt. > In any case, here is an example run of a simple single-homed guest over > standard GigE. Whats interesting here is that .qnotify to .notify > ratio, as this is the interrupt-to-signal ratio. In this case, its > 170047/151918, which comes out to about 11% savings in interrupt injections: > > vbus-guest:/home/ghaskins # netperf -H dev > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > dev.laurelwood.net (192.168.1.10) port 0 AF_INET > Recv SendSend > Socket Socket Message Elapsed > Size SizeSize Time Throughput > bytes bytes bytessecs.10^6bits/sec > > 1048576 16384 1638410.01 940.77 > vbus-guest:/home/ghaskins # cat /sys/kernel/debug/pci-to-vbus-bridge >.events: 170048 >.qnotify : 151918 >.qinject : 0 >.notify: 170047 >.inject: 18238 >.bridgecalls : 18 >.buscalls : 12 > vbus-guest:/home/ghaskins # cat /proc/interrupts > CPU0 > 0: 87 IO-APIC-edge timer > 1: 6 IO-APIC-edge i8042 > 4:733 IO-APIC-edge serial > 6: 2 IO-APIC-edge floppy > 7: 0 IO-APIC-edge parport0 > 8: 0 IO-APIC-edge rtc0 > 9: 0 IO-APIC-fasteoi acpi >10: 0 IO-APIC-fasteoi virtio1 >12: 90 IO-APIC-edge i8042 >14: 3041 IO-APIC-edge ata_piix >15: 1008 IO-APIC-edge ata_piix >24: 151933 PCI-MSI-edge vbus >25: 0 PCI-MSI-edge virtio0-config >26:190 PCI-MSI-edge virtio0-input >27: 28 PCI-MSI-edge virtio0-output > NMI: 0 Non-maskable interrupts > LOC: 9854 Local timer interrupts > SPU: 0 Spurious interrupts > CNT: 0 Performance counter interrupts > PND: 0 Performance pending work > RES: 0 Rescheduling interrupts > CAL: 0 Function call interrupts > TLB: 0 TLB shootdowns > TRM: 0 Thermal event interrupts > THR: 0 Threshold APIC interrupts > MCE: 0 Machine check exceptions > MCP: 1 Machine check polls > ERR: 0 > MIS: 0 > > Its important to note here that we are actually loo
Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication
Am Mittwoch 30 September 2009 19:13:21 schrieb Amit Shah: > On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote: > > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah: > > > Great, thanks. However I was thinking of moving this init to the > > > probe() routine instead of in the init_conosle routine just because > > > multiple consoles can be added and we don't want to init this each > > > time.. just once in probe is fine. > > > > If you have new patch CC me and I can give it a spin. > > Hey Christian, > > I have a new patch that changes a few things: > - moves the put_char fix to probe instead of doing it in > init_port_console(), which gets called on each console port found. > - uses port->id instead of a static hvc_vtermno to pass on a value to > hvc_alloc(). Motivation explained within comments in the code. > - A few other changes that introduce and make use of port->vcon instead > of accessing the static virtconsole directly -- aimed at easing future > fix to have multiple virtio-console devices. > > It would be great if you could test this. The basic stuff seems to work, but when I did a console resize I get: <0>[ cut here ] <2>kernel BUG at drivers/s390/kvm/kvm_virtio.c:117! <4>illegal operation: 0001 [#1] SMP <4>Modules linked in: dm_multipath scsi_dh sunrpc ipv6 binfmt_misc dm_mod virtio_rng rng_core <4>CPU: 0 Not tainted 2.6.31-selfgit-08936-g851b147-dirty #172 <4>Process events/0 (pid: 19, task: 0c4f3040, ksp: 0c305cc8) <4>Krnl PSW : 070420018000 00460bf2 (kvm_get+0x86/0x90) <4> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 <4>Krnl GPRS: 00030001 0004 0008 0004 <4> 0c305e2c 0004 00c56308 <4> 003b863c 0c4f3040 00460b6c 00903e28 <4> 0c80 00525a90 003b8682 0c305d88 <4>Krnl Code: 00460be6: a737fff9brctg %r3,460bd8 <4> 00460bea: a7f4ffeebrc 15,460bc6 <4> 00460bee: a7f40001brc 15,460bf0 <4> >00460bf2: a7f4brc 15,460bf2 <4> 00460bf6: d20040001000mvc 0(1,%r4),0(%r1) <4> 00460bfc: ebaff0680024stmg %r10,%r15,104(%r15) <4> 00460c02: c0d81b7flarl%r13,564300 <4> 00460c08: a7f11fc0tmll%r15,8128 <4>Call Trace: <4>([<>] 0x0) <4> [<0015d43e>] worker_thread+0x1ea/0x2d0 <4> [<00163666>] kthread+0x9a/0xa4 <4> [<0010a212>] kernel_thread_starter+0x6/0xc <4> [<0010a20c>] kernel_thread_starter+0x0/0xc <4>Last Breaking-Event-Address: <4> [<00460bee>] kvm_get+0x82/0x90 <4> One of the config->get() related changes is probably wrong. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
