Re: [KVM-AUTOTEST PATCH 4/5] KVM test: kvm_subprocess: rename get_command_status_output() and friends
- "Michael Goldish" wrote: > From: "Michael Goldish" > To: autot...@test.kernel.org, kvm@vger.kernel.org > Cc: "Michael Goldish" > Sent: Wednesday, October 27, 2010 12:49:43 AM GMT +08:00 Beijing / Chongqing > / Hong Kong / Urumqi > Subject: [KVM-AUTOTEST PATCH 4/5] KVM test: kvm_subprocess: rename > get_command_status_output() and friends > > get_command_status_output() -> cmd_status_output() > get_command_output() -> cmd_output() > get_command_status() -> cmd_status() Any reason for these change? coding style issue? If there is no necessary reason, we better do not change them. These functions is widely used, the change may introduce errors. Changing interface will bring some workload and risk. At least we need change all our internal case when merging with upstream. > > Signed-off-by: Michael Goldish > --- > client/tests/kvm/kvm_subprocess.py | 27 > +-- > client/tests/kvm/kvm_test_utils.py | 20 > +++--- > client/tests/kvm/tests/ethtool.py | 16 > ++-- > client/tests/kvm/tests/guest_s4.py |8 +++--- > client/tests/kvm/tests/guest_test.py |3 +- > client/tests/kvm/tests/iofuzz.py |2 +- > client/tests/kvm/tests/ioquit.py |4 +- > client/tests/kvm/tests/iozone_windows.py |4 +- > client/tests/kvm/tests/ksm_overcommit.py |4 +- > client/tests/kvm/tests/linux_s3.py |4 +- > client/tests/kvm/tests/migration.py|7 ++--- > client/tests/kvm/tests/multicast.py|8 +++--- > client/tests/kvm/tests/netperf.py |4 +- > client/tests/kvm/tests/nic_promisc.py |4 +- > client/tests/kvm/tests/nicdriver_unload.py |4 +- > client/tests/kvm/tests/pci_hotplug.py |6 ++-- > client/tests/kvm/tests/physical_resources_check.py |2 +- > client/tests/kvm/tests/timedrift.py|2 +- > client/tests/kvm/tests/vlan.py | 11 +++ > client/tests/kvm/tests/whql_client_install.py | 10 +++--- > client/tests/kvm/tests/whql_submission.py |4 +- > 21 files changed, 75 insertions(+), 79 deletions(-) > > diff --git a/client/tests/kvm/kvm_subprocess.py > b/client/tests/kvm/kvm_subprocess.py > index c92910c..c8caab2 100755 > --- a/client/tests/kvm/kvm_subprocess.py > +++ b/client/tests/kvm/kvm_subprocess.py > @@ -1103,7 +1103,7 @@ class kvm_shell_session(kvm_expect): > @param prompt: Regular expression describing the shell's > prompt line. > @param status_test_command: Command to be used for getting > the last > exit status of commands run inside the shell (used > by > -get_command_status_output() and friends). > +cmd_status_output() and friends). > """ > # Init the superclass > kvm_expect.__init__(self, command, id, auto_close, echo, > linesep, > @@ -1193,8 +1193,8 @@ class kvm_shell_session(kvm_expect): > return o > > > -def get_command_output(self, cmd, timeout=30.0, > internal_timeout=None, > - print_func=None): > +def cmd_output(self, cmd, timeout=30.0, internal_timeout=None, > + print_func=None): > """ > Send a command and return its output. > > @@ -1237,8 +1237,8 @@ class kvm_shell_session(kvm_expect): > return remove_last_nonempty_line(remove_command_echo(o, > cmd)) > > > -def get_command_status_output(self, cmd, timeout=30.0, > - internal_timeout=None, > print_func=None): > +def cmd_status_output(self, cmd, timeout=30.0, > internal_timeout=None, > + print_func=None): > """ > Send a command and return its exit status and output. > > @@ -1257,11 +1257,10 @@ class kvm_shell_session(kvm_expect): > @raise ShellStatusError: Raised if the exit status cannot be > obtained > @raise ShellError: Raised if an unknown error occurs > """ > -o = self.get_command_output(cmd, timeout, internal_timeout, > print_func) > +o = self.cmd_output(cmd, timeout, internal_timeout, > print_func) > try: > # Send the 'echo $?' (or equivalent) command to get the > exit status > -s = self.get_command_output(self.status_test_command, > 10, > -internal_timeout) > +s = self.cmd_output(self.status_test_command, 10, > internal_timeout) > except ShellError: > raise ShellStatusError(cmd, o) > > @@ -1273,8 +1272,8 @@ class kvm_shell_session(kvm_expect): > raise ShellStatusError(cmd, o) > > > -def get_command_status(self, cmd, timeout=30.0, > internal_timeout=None, > - print_func=None): > +def cmd_status
Re: KVM devices assignment; PCIe AER?
On Tue, 26 Oct 2010, Chris Wright wrote: I would totally agree with you if the alternative implementation to this legacy mode would be available in a relatively short time frame. I'm not sure about that? Depends on how quickly you can help whip it into shape ;) Humm, this is not an easy question; IMHO the biggest problem of going with VFIO for devices assignment is interruption handling. VFIO knows how to signal an eventfd but doesn't know about 'kvm_set_irq' for example. I think that VFIO will require some adaptation for that matter. Because qemu device assignment is working on VFIO I'm making the assumption that kvm iommu code can be entirely deprecated. Maybe I'm totally wrong here? That's why I asked about how you were implementing, for example, the AER extended capability exposure. Capabilities are a problem for the current code (forget about extended capabilities, just regular capabilities). We depend on Q35 PCIe chipset for that matter. Do this answer your question? thanks, Etienne -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v13 10/16] Add a hook to intercept external buffers from NIC driver.
>-Original Message-
>From: David Miller [mailto:da...@davemloft.net]
>Sent: Tuesday, October 19, 2010 11:24 PM
>To: Xin, Xiaohui
>Cc: net...@vger.kernel.org; kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
>m...@redhat.com; mi...@elte.hu; herb...@gondor.apana.org.au;
>jd...@linux.intel.com
>Subject: Re: [PATCH v13 10/16] Add a hook to intercept external buffers from
>NIC driver.
>
>From: xiaohui@intel.com
>Date: Fri, 15 Oct 2010 17:12:11 +0800
>
>> @@ -2891,6 +2922,11 @@ static int __netif_receive_skb(struct sk_buff *skb)
>> ncls:
>> #endif
>>
>> +/* To intercept mediate passthru(zero-copy) packets here */
>> +skb = handle_mpassthru(skb, &pt_prev, &ret, orig_dev);
>> +if (!skb)
>> +goto out;
>> +
>> /* Handle special case of bridge or macvlan */
>> rx_handler = rcu_dereference(skb->dev->rx_handler);
>> if (rx_handler) {
>
>If you consume the packet here, devices in passthru mode cannot
>be use with bonding.
>
>But there is nothing that prevents a bond being created with such
>a device.
>
>So we have to either prevent such configurations (bad) or make
>it work somehow (good) :-)
The big picture may like this:
To prevent such configurations, we should add code to check in both
mp and bonding driver. If a nic is in zero-copy mode , bonding can't
be made with it, and if nic is in bonding mode, we can't bind the device
to do zero-copy.
If we want to support such configurations, it also has some constraints.
If bonding is created first, we need code to check if all the slaves support
zero-copy mode, and if yes, all the slaves should be assigned a same
page_ctor(), all the packets received should be intercepted with master nic.
If not, fails.
If zero-copy is enabled first, bonding created with it should fail.
Somehow, it seems not a trivial work to support it now. Can we support it
later and as a todo with our current work?
Thanks
Xiaohui
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
* Etienne Martineau (etmartin...@gmail.com) wrote: > On Tue, 26 Oct 2010, Chris Wright wrote: > >Right, and adding more to the existing KVM code which we are hoping to > >push to legacy support mode doesn't sound like a great idea. > > I would totally agree with you if the alternative implementation to > this legacy mode would be available in a relatively short time > frame. I'm not sure about that? Depends on how quickly you can help whip it into shape ;) That's why I asked about how you were implementing, for example, the AER extended capability exposure. Capabilities are a problem for the current code (forget about extended capabilities, just regular capabilities). > >>In that context, do you think it's acceptable for KVM to be the > >>driver of the assigned devices? OR should we simply add the AER > >>logic into existing pci-stub and relay the information to user-space > >>through eventfd... > > > >I'm reluctant to add logic to pci-stub, but VFIO should be able to > >handle this directly. > > I agree that VFIO should be able to do the job. It would be great to see some effort on this. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
On Tue, 26 Oct 2010, Chris Wright wrote: Right, and adding more to the existing KVM code which we are hoping to push to legacy support mode doesn't sound like a great idea. I would totally agree with you if the alternative implementation to this legacy mode would be available in a relatively short time frame. I'm not sure about that? In that context, do you think it's acceptable for KVM to be the driver of the assigned devices? OR should we simply add the AER logic into existing pci-stub and relay the information to user-space through eventfd... I'm reluctant to add logic to pci-stub, but VFIO should be able to handle this directly. I agree that VFIO should be able to do the job. thanks, -Etienne -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
On Tue, Oct 26, 2010 at 03:15:58PM -0700, Chris Wright wrote: > > I think we need to register with PCI and provide > > 'pci_error_handlers' callback if we wants to receive AER > > notification. > > Right, and adding more to the existing KVM code which we are hoping to > push to legacy support mode doesn't sound like a great idea. If it's a small patch, I think Avi mentioned that he might consider features too. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH iproute2] Add passthru mode and support 'mode' parameter with macvtap devices
Support a new 'passthru' mode with macvlan and 'mode' parameter
with macvtap devices.
Signed-off-by: Sridhar Samudrala
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index f5bb2dc..23de79e 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -230,6 +230,7 @@ enum macvlan_mode {
MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
MACVLAN_MODE_VEPA= 2, /* talk to other ports through ext bridge */
MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
+ MACVLAN_MODE_PASSTHRU = 8, /* take over the underlying device */
};
/* SR-IOV virtual function management section */
diff --git a/ip/Makefile b/ip/Makefile
index 2f223ca..6054e8a 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -3,7 +3,7 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o \
ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o iptuntap.o \
ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o \
iplink_vlan.o link_veth.o link_gre.o iplink_can.o \
-iplink_macvlan.o
+iplink_macvlan.o iplink_macvtap.o
RTMONOBJ=rtmon.o
diff --git a/ip/iplink_macvlan.c b/ip/iplink_macvlan.c
index a3c78bd..97787f9 100644
--- a/ip/iplink_macvlan.c
+++ b/ip/iplink_macvlan.c
@@ -48,6 +48,8 @@ static int macvlan_parse_opt(struct link_util *lu, int argc,
char **argv,
mode = MACVLAN_MODE_VEPA;
else if (strcmp(*argv, "bridge") == 0)
mode = MACVLAN_MODE_BRIDGE;
+ else if (strcmp(*argv, "passthru") == 0)
+ mode = MACVLAN_MODE_PASSTHRU;
else
return mode_arg();
@@ -82,6 +84,7 @@ static void macvlan_print_opt(struct link_util *lu, FILE *f,
struct rtattr *tb[]
mode == MACVLAN_MODE_PRIVATE ? "private"
: mode == MACVLAN_MODE_VEPA? "vepa"
: mode == MACVLAN_MODE_BRIDGE ? "bridge"
+ : mode == MACVLAN_MODE_PASSTHRU ? "passthru"
:"unknown");
}
diff --git a/ip/iplink_macvtap.c b/ip/iplink_macvtap.c
new file mode 100644
index 000..040cc68
--- /dev/null
+++ b/ip/iplink_macvtap.c
@@ -0,0 +1,93 @@
+/*
+ * iplink_macvtap.cmacvtap device support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "rt_names.h"
+#include "utils.h"
+#include "ip_common.h"
+
+static void explain(void)
+{
+ fprintf(stderr,
+ "Usage: ... macvtap mode { private | vepa | bridge | passthru
}\n"
+ );
+}
+
+static int mode_arg(void)
+{
+fprintf(stderr, "Error: argument of \"mode\" must be \"private\", "
+ "\"vepa\" or \"bridge\" \"passthru\"\n");
+return -1;
+}
+
+static int macvtap_parse_opt(struct link_util *lu, int argc, char **argv,
+ struct nlmsghdr *n)
+{
+ while (argc > 0) {
+ if (matches(*argv, "mode") == 0) {
+ __u32 mode = 0;
+ NEXT_ARG();
+
+ if (strcmp(*argv, "private") == 0)
+ mode = MACVLAN_MODE_PRIVATE;
+ else if (strcmp(*argv, "vepa") == 0)
+ mode = MACVLAN_MODE_VEPA;
+ else if (strcmp(*argv, "bridge") == 0)
+ mode = MACVLAN_MODE_BRIDGE;
+ else if (strcmp(*argv, "passthru") == 0)
+ mode = MACVLAN_MODE_PASSTHRU;
+ else
+ return mode_arg();
+
+ addattr32(n, 1024, IFLA_MACVLAN_MODE, mode);
+ } else if (matches(*argv, "help") == 0) {
+ explain();
+ return -1;
+ } else {
+ fprintf(stderr, "macvtap: what is \"%s\"?\n", *argv);
+ explain();
+ return -1;
+ }
+ argc--, argv++;
+ }
+
+ return 0;
+}
+
+static void macvtap_print_opt(struct link_util *lu, FILE *f, struct rtattr
*tb[])
+{
+ __u32 mode;
+
+ if (!tb)
+ return;
+
+ if (!tb[IFLA_MACVLAN_MODE] ||
+ RTA_PAYLOAD(tb[IFLA_MACVLAN_MODE]) < sizeof(__u32))
+ return;
+
+ mode = *(__u32 *)RTA_DATA(tb[IFLA_VLAN_ID]);
+ fprintf(f, " mode %s ",
+ mode == MACVLAN_MODE_PRIVATE ? "private"
+ : mode == MACVLAN_MODE_VEPA? "vepa"
+ : mode == MACVLAN_MODE_BRIDGE ? "bridge"
+ : mode == MACVLAN_MO
[RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the underlying device
With the current default macvtap mode, a KVM guest using virtio with
macvtap backend has the following limitations.
- cannot change/add a mac address on the guest virtio-net
- cannot create a vlan device on the guest virtio-net
- cannot enable promiscuous mode on guest virtio-net
This patch introduces a new mode called 'passthru' when creating a
macvlan device which allows takeover of the underlying device and
passing it to a guest using virtio with macvtap backend.
Only one macvlan device is allowed in passthru mode and it inherits
the mac address from the underlying device and sets it in promiscuous
mode to receive and forward all the packets.
Thanks
Sridhar
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 0ef0eb0..bca3cb7 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -38,6 +38,7 @@ struct macvlan_port {
struct hlist_head vlan_hash[MACVLAN_HASH_SIZE];
struct list_headvlans;
struct rcu_head rcu;
+ boolpassthru;
};
#define macvlan_port_get_rcu(dev) \
@@ -169,6 +170,7 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff
*skb)
macvlan_broadcast(skb, port, NULL,
MACVLAN_MODE_PRIVATE |
MACVLAN_MODE_VEPA|
+ MACVLAN_MODE_PASSTHRU|
MACVLAN_MODE_BRIDGE);
else if (src->mode == MACVLAN_MODE_VEPA)
/* flood to everyone except source */
@@ -185,7 +187,10 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff
*skb)
return skb;
}
- vlan = macvlan_hash_lookup(port, eth->h_dest);
+ if (port->passthru)
+ vlan = list_first_entry(&port->vlans, struct macvlan_dev, list);
+ else
+ vlan = macvlan_hash_lookup(port, eth->h_dest);
if (vlan == NULL)
return skb;
@@ -284,6 +289,11 @@ static int macvlan_open(struct net_device *dev)
struct net_device *lowerdev = vlan->lowerdev;
int err;
+ if (vlan->port->passthru) {
+ dev_set_promiscuity(lowerdev, 1);
+ goto hash_add;
+ }
+
err = -EBUSY;
if (macvlan_addr_busy(vlan->port, dev->dev_addr))
goto out;
@@ -296,6 +306,8 @@ static int macvlan_open(struct net_device *dev)
if (err < 0)
goto del_unicast;
}
+
+hash_add:
macvlan_hash_add(vlan);
return 0;
@@ -310,12 +322,18 @@ static int macvlan_stop(struct net_device *dev)
struct macvlan_dev *vlan = netdev_priv(dev);
struct net_device *lowerdev = vlan->lowerdev;
+ if (vlan->port->passthru) {
+ dev_set_promiscuity(lowerdev, -1);
+ goto hash_del;
+ }
+
dev_mc_unsync(lowerdev, dev);
if (dev->flags & IFF_ALLMULTI)
dev_set_allmulti(lowerdev, -1);
dev_uc_del(lowerdev, dev->dev_addr);
+hash_del:
macvlan_hash_del(vlan);
return 0;
}
@@ -549,6 +567,7 @@ static int macvlan_port_create(struct net_device *dev)
if (port == NULL)
return -ENOMEM;
+ port->passthru = false;
port->dev = dev;
INIT_LIST_HEAD(&port->vlans);
for (i = 0; i < MACVLAN_HASH_SIZE; i++)
@@ -593,6 +612,7 @@ static int macvlan_validate(struct nlattr *tb[], struct
nlattr *data[])
case MACVLAN_MODE_PRIVATE:
case MACVLAN_MODE_VEPA:
case MACVLAN_MODE_BRIDGE:
+ case MACVLAN_MODE_PASSTHRU:
break;
default:
return -EINVAL;
@@ -661,6 +681,10 @@ int macvlan_common_newlink(struct net *src_net, struct
net_device *dev,
}
port = macvlan_port_get(lowerdev);
+ /* Only 1 macvlan device can be created in passthru mode */
+ if (port->passthru)
+ return -EINVAL;
+
vlan->lowerdev = lowerdev;
vlan->dev = dev;
vlan->port = port;
@@ -671,6 +695,13 @@ int macvlan_common_newlink(struct net *src_net, struct
net_device *dev,
if (data && data[IFLA_MACVLAN_MODE])
vlan->mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
+ if (vlan->mode == MACVLAN_MODE_PASSTHRU) {
+ if (!list_empty(&port->vlans))
+ return -EINVAL;
+ port->passthru = true;
+ memcpy(dev->dev_addr, lowerdev->dev_addr, ETH_ALEN);
+ }
+
err = register_netdevice(dev);
if (err < 0)
goto destroy_port;
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 2fc66dd..8454805 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -232,6 +232,7 @@ enum macvlan_mode {
MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans
Re: KVM devices assignment; PCIe AER?
* Etienne Martineau (etmartin...@gmail.com) wrote: > > > On Tue, 26 Oct 2010, Chris Wright wrote: > > >>***One of the aspect I'm not clear is the strategy for > >>device-assignment under KVM? > >>A) Move to VFIO; [/dev/iommu, /dev/vfio] > > > >Long term, hopefully VFIO > > > >>B) KVM as a driver for the assigned devices; [sysfs/ ioctls..] > > > >Short term (i.e. current qemu-kvm tree...this is what we have now and > >will continue to until plan A) gets more mature). > > > Strictly speaking, I don't really agree with 'B' being the current > implementation. Correct me if I'm wrong but for assigned devices, > kvm does a look up for the device and eventually obtain a handle to > it (struct pci_dev*) without doing a proper 'pci_register_driver'. OK, not a PCI driver per-se (that's pci-stub), but KVM owns the process of registering interrupt handler, programming iommu, etc. > I think we need to register with PCI and provide > 'pci_error_handlers' callback if we wants to receive AER > notification. Right, and adding more to the existing KVM code which we are hoping to push to legacy support mode doesn't sound like a great idea. > In that context, do you think it's acceptable for KVM to be the > driver of the assigned devices? OR should we simply add the AER > logic into existing pci-stub and relay the information to user-space > through eventfd... I'm reluctant to add logic to pci-stub, but VFIO should be able to handle this directly. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
On Tue, 26 Oct 2010, Chris Wright wrote: ***One of the aspect I'm not clear is the strategy for device-assignment under KVM? A) Move to VFIO; [/dev/iommu, /dev/vfio] Long term, hopefully VFIO B) KVM as a driver for the assigned devices; [sysfs/ ioctls..] Short term (i.e. current qemu-kvm tree...this is what we have now and will continue to until plan A) gets more mature). Strictly speaking, I don't really agree with 'B' being the current implementation. Correct me if I'm wrong but for assigned devices, kvm does a look up for the device and eventually obtain a handle to it (struct pci_dev*) without doing a proper 'pci_register_driver'. I think we need to register with PCI and provide 'pci_error_handlers' callback if we wants to receive AER notification. In that context, do you think it's acceptable for KVM to be the driver of the assigned devices? OR should we simply add the AER logic into existing pci-stub and relay the information to user-space through eventfd... Thanks, Etienne -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
On Tue, Oct 26, 2010 at 01:24:00PM -0700, Etienne Martineau wrote: > ***One of the aspect I'm not clear is the strategy for > device-assignment under KVM? > A) Move to VFIO; [/dev/iommu, /dev/vfio] > B) KVM as a driver for the assigned devices; [sysfs/ ioctls..] > C) No plan for short term > > Alex, Chris, Michael thanks for your reply. > -Etienne We will have to keep supporting B for a long while. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
* Etienne Martineau (etmartin...@gmail.com) wrote: > ***Background context: > We are using kvm on a x86 based platform. For performance reason, we > use devices assignment. The type of devices we have to deal with is > mostly custom ASICs but we also have standard stuff (ex 82599EB > 10-GigabitSR-IOV). > > AER handling in guest VM is very important to us. Most of our > drivers assume timely notification in cases of PCIe AER. Failure to > provide such support will result in very undesireable behavior at > the other end :) > > In our cases, AER is not strictly function of the hardware 'quality' > but also tied to the way the user can interact with the system (by > pulling a card on the fly for example). > > ***Q35, VFIO: > I'm aware of the PCIe Q35 chipset work that Isaku is working on. I > have a college that is working actively on merging the change into > our qemu-kvm branch. > > I'm also familiar with VFIO. I've seen the work from Alex on the > qemu VFIO front. Not too sure how this is going to work on qemu-kvm? > OR maybe it's because I'm confused about the long term plan for user > space [qemu vs qemu-kvm] branch? The Plan (TM) is for qemu-kvm to be just a staging branch for qemu. There are a few bits left in qemu-kvm (I'm sure you're aware since you're working with them ;) that aren't yet upstream. The device assignment code is one of those bits. Ideally, we could get KVM out of the business of being a device driver for assigned host devices and move all of that functionality to VFIO. And when looking at adding significant new functionality like AER, scoping VFIO would be very useful. > ***One of the aspect I'm not clear is the strategy for > device-assignment under KVM? > A) Move to VFIO; [/dev/iommu, /dev/vfio] Long term, hopefully VFIO > B) KVM as a driver for the assigned devices; [sysfs/ ioctls..] Short term (i.e. current qemu-kvm tree...this is what we have now and will continue to until plan A) gets more mature). thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c
On 10/26/2010 01:27 PM, Andi Kleen wrote: >> That is an issue too, as 3.x does a lot fewer optimizations than 4.x. > > Well to be fair the default -Os build disables most of the fancy stuff > (and the resulting code is often terrible) > > I guess it doesn't matter too much, at least not with the > CONFIG_CC_OPTIMIZE_SIZE default. > Yes, it would be nice to have a setting which is "optimize but don't bloat excessively." -hpa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c
> That is an issue too, as 3.x does a lot fewer optimizations than 4.x. Well to be fair the default -Os build disables most of the fancy stuff (and the resulting code is often terrible) I guess it doesn't matter too much, at least not with the CONFIG_CC_OPTIMIZE_SIZE default. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
***Background context: We are using kvm on a x86 based platform. For performance reason, we use devices assignment. The type of devices we have to deal with is mostly custom ASICs but we also have standard stuff (ex 82599EB 10-GigabitSR-IOV). AER handling in guest VM is very important to us. Most of our drivers assume timely notification in cases of PCIe AER. Failure to provide such support will result in very undesireable behavior at the other end :) In our cases, AER is not strictly function of the hardware 'quality' but also tied to the way the user can interact with the system (by pulling a card on the fly for example). ***Q35, VFIO: I'm aware of the PCIe Q35 chipset work that Isaku is working on. I have a college that is working actively on merging the change into our qemu-kvm branch. I'm also familiar with VFIO. I've seen the work from Alex on the qemu VFIO front. Not too sure how this is going to work on qemu-kvm? OR maybe it's because I'm confused about the long term plan for user space [qemu vs qemu-kvm] branch? ***One of the aspect I'm not clear is the strategy for device-assignment under KVM? A) Move to VFIO; [/dev/iommu, /dev/vfio] B) KVM as a driver for the assigned devices; [sysfs/ ioctls..] C) No plan for short term Alex, Chris, Michael thanks for your reply. -Etienne On Tue, 26 Oct 2010, Michael S. Tsirkin wrote: On Tue, Oct 26, 2010 at 09:41:12AM -0700, etmartin101 wrote: Chris, Michael et al. Part of the project I'm working on, we are looking at extending the device assignment capabilities to provide support for PCIe AER. Ideally, the host would register for AER (for every assigned devices) and pass them up to Qemu. As of now, one of the problem is that KVM is not a driver for the assigned devices. I've seen Chris's slides from KVM conf 2010 but I haven't seen any patches or discussion on that topic... On another front, I've seen the work from Michael around 'uio_pci_generic' and some of his comments: " It's expected that more features of interest to virtualization will be added to this driver in the future. Possibilities are: mmap for device resources, MSI/MSI-X, eventfd (to interface with kvm), iommu." I think that extending 'uio_pci_generic' to support AER is relatively straight forward (assuming eventfd support from UIO). Any thought? thanks, -Etienne On the qemu side, patches for aer support are being worked on, pls take a look, likely there's some synergy there. On the kernel side, AER for uio sounds fine, but the features listed above are not yet supported, so you'd have to code them up too. There's a uiommu driver from Tom Lyon that does the iommu bit. Alex and Tom have been working on a VFIO driver which is not based on the uio framework. You can try joining forces. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
On Tue, Oct 26, 2010 at 09:41:12AM -0700, etmartin101 wrote: > Chris, Michael et al. > > Part of the project I'm working on, we are looking at extending the > device assignment capabilities to provide support for PCIe AER. BTW, what's the motivation to support this feature? -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
On Tue, Oct 26, 2010 at 09:41:12AM -0700, etmartin101 wrote: > Chris, Michael et al. > > Part of the project I'm working on, we are looking at extending the > device assignment capabilities to provide support for PCIe AER. > Ideally, the host would register for AER (for every assigned > devices) and pass them up to Qemu. > > As of now, one of the problem is that KVM is not a driver for the > assigned devices. I've seen Chris's slides from KVM conf 2010 but I > haven't seen any patches or discussion on that topic... > > On another front, I've seen the work from Michael around 'uio_pci_generic' > and some of his comments: > " It's expected that more features of interest to virtualization will be > added to this driver in the future. Possibilities are: mmap for device > resources, MSI/MSI-X, eventfd (to interface with kvm), iommu." > > I think that extending 'uio_pci_generic' to support AER is > relatively straight forward (assuming eventfd support from UIO). > > Any thought? > > thanks, > -Etienne On the qemu side, patches for aer support are being worked on, pls take a look, likely there's some synergy there. On the kernel side, AER for uio sounds fine, but the features listed above are not yet supported, so you'd have to code them up too. There's a uiommu driver from Tom Lyon that does the iommu bit. Alex and Tom have been working on a VFIO driver which is not based on the uio framework. You can try joining forces. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks
On Tue, Oct 26, 2010 at 5:35 PM, Avi Kivity wrote: > On 10/26/2010 07:27 PM, Anthony Liguori wrote: >>> >>> Sorry, I don't follow your meaning. >>> >>> When I said "size is implied" I meant that the IOPort object has a >>> separate function pointer for sizes 1, 2, and 4, so it ioport_register() >>> doesn't need a size parameter. But I don't see how that relates to your >>> comment. >> >> >> Yeah, I don't think it makes sense to combine "this is how to dispatch >> I/O" with "this is a region of I/O address space". > > Oh, so Blue meant the size of the region in ports, not the size of the > individual ports. I think that putting the range length (but not base > address) in the IOPort structure may make sense. Yes, that's what I meant. Consider for example the handlers: they expect that the port is within some range. >> >> I think an IORegion should contain an IOPort structure though. I think >> the name needs rethinking. >> >> Maybe: >> >> struct PortIOHandler; >> struct MemoryIOHandler; > > Why two types? I think some devices use PIO on a PC and MMIO on other > architectures. Sharing the type would allow sharing code. Then there are the functions provided by rwhandler.c. I think that interface makes even more sense compared to 8/16/32 (and 64?) bit handlers in many cases. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
* etmartin101 (etmartin...@gmail.com) wrote: > Part of the project I'm working on, we are looking at extending the > device assignment capabilities to provide support for PCIe AER. How did you plan to do this? Right now we only provide PCI capabilities (not Extended Capabilities). > Ideally, the host would register for AER (for every assigned > devices) and pass them up to Qemu. This should be so for devices iff they support AER to begin with. Having proper chipset support in QEMU (PCIe + AER) also a step. > As of now, one of the problem is that KVM is not a driver for the > assigned devices. I've seen Chris's slides from KVM conf 2010 but I > haven't seen any patches or discussion on that topic... > > On another front, I've seen the work from Michael around 'uio_pci_generic' > and some of his comments: > " It's expected that more features of interest to virtualization will be > added to this driver in the future. Possibilities are: mmap for device > resources, MSI/MSI-X, eventfd (to interface with kvm), iommu." > > I think that extending 'uio_pci_generic' to support AER is > relatively straight forward (assuming eventfd support from UIO). Did you look at VFIO? thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c
On 10/26/2010 10:01 AM, Andi Kleen wrote: >> Not unless they are actively known to break. People get huffy about it > > Well they do -- i just found out. Sounds like a good reason to put in a warning or error. >> because even if it is known to have problems it doesn't break *their* >> particular configuration. I'm getting to be of the opinion that people >> who compile modern kernels with ancient compilers and expect it to work >> are suffering from some particular kind of insanity -- it's nothing the >> distros do. The only exception are embedded people who compile with the >> latest 3.4 gcc; they have explained they do so because newer gccs have >> too many dependencies (the actual compiler, not the generated code) and >> for speed. > > At least in the old days the main reason for gcc 3 was build speed. > AKPM and some others used to be fond of that. > > 3.x is apparently much faster than 4.x That is an issue too, as 3.x does a lot fewer optimizations than 4.x. -hpa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM devices assignment; PCIe AER?
On Tue, Oct 26, 2010 at 10:41 AM, etmartin101 wrote: > Chris, Michael et al. > > Part of the project I'm working on, we are looking at extending the > device assignment capabilities to provide support for PCIe AER. > Ideally, the host would register for AER (for every assigned devices) and > pass them up to Qemu. > > As of now, one of the problem is that KVM is not a driver for the > assigned devices. I've seen Chris's slides from KVM conf 2010 but I > haven't seen any patches or discussion on that topic... > > On another front, I've seen the work from Michael around 'uio_pci_generic' > and some of his comments: > " It's expected that more features of interest to virtualization will be > added to this driver in the future. Possibilities are: mmap for device > resources, MSI/MSI-X, eventfd (to interface with kvm), iommu." > > I think that extending 'uio_pci_generic' to support AER is relatively > straight forward (assuming eventfd support from UIO). A lot of work has been going into a new "VFIO" driver that has taken over in the virtualization direction that uio_pci_generic was starting to go. Search the mailing list for it. That's probably where we'd want to focus AER efforts. I posted a qemu VFIO driver RFC a few months ago and I'm still actively working on it. We currently pass the device capabilities to the guest via an emulation layer in the VFIO kernel driver. This layer might be going away as we try to simplify the kernel side, which would mean more capability work in qemu. We also need the update to the Q35 chipset that Isaku is working on to be able to have an express root port to signal AER events. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
extraneous allocation in qemu-kvm's hw/pc_piix.c
While doing some source review I noticed what appears to be an extraneous call to pc_allocate_cpu_irq() in qemu-kvm and which does not appear in qemu. From the git history it almost looks like b725a661eb38c93086e0b98f626a3864ae8651b8 mis-merged 845773ab03a8dde681ff1b929bbb41e67d0131a6? At any rate qemu-kvm got patched differently than qemu for the piix split out and this line appears to allocate something which then goes unused. Signed-off-by: Tim Pepper --- diff --git a/hw/pc_piix.c b/hw/pc_piix.c index 3d07ce5..781d5ad 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -128,7 +128,6 @@ static void pc_init1(ram_addr_t ram_size, isa_bus_irqs(isa_irq); pc_register_ferr_irq(isa_reserve_irq(13)); -cpu_irq = pc_allocate_cpu_irq(); pc_vga_init(pci_enabled? pci_bus: NULL); -- Tim Pepper IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST PATCH 5/5] [RFC] KVM test: kvm_subprocess: rename kvm_shell_session and friends
PEP 8 states that class names should use the CapWords convention.
kvm_spawn -> Spawn
kvm_tail -> Tail
kvm_expect -> Expect
kvm_shell_session -> ShellSession
This is an RFC because I wonder if the proposed names are too general, even
though they are usually prefixed by 'kvm_subprocess.'.
Signed-off-by: Michael Goldish
---
client/tests/kvm/kvm_preprocessing.py |2 +-
client/tests/kvm/kvm_scheduler.py |2 +-
client/tests/kvm/kvm_subprocess.py| 60
client/tests/kvm/kvm_utils.py | 15
client/tests/kvm/kvm_vm.py|6 ++--
5 files changed, 42 insertions(+), 43 deletions(-)
diff --git a/client/tests/kvm/kvm_preprocessing.py
b/client/tests/kvm/kvm_preprocessing.py
index 1ddf99b..5ec38fb 100644
--- a/client/tests/kvm/kvm_preprocessing.py
+++ b/client/tests/kvm/kvm_preprocessing.py
@@ -204,7 +204,7 @@ def preprocess(test, params, env):
if "tcpdump" not in env and params.get("run_tcpdump", "yes") == "yes":
cmd = "%s -npvi any 'dst port 68'" % kvm_utils.find_command("tcpdump")
logging.debug("Starting tcpdump (%s)...", cmd)
-env["tcpdump"] = kvm_subprocess.kvm_tail(
+env["tcpdump"] = kvm_subprocess.Tail(
command=cmd,
output_func=_update_address_cache,
output_params=(env["address_cache"],))
diff --git a/client/tests/kvm/kvm_scheduler.py
b/client/tests/kvm/kvm_scheduler.py
index f1adb39..aa581ad 100644
--- a/client/tests/kvm/kvm_scheduler.py
+++ b/client/tests/kvm/kvm_scheduler.py
@@ -78,7 +78,7 @@ class scheduler:
for obj in env.values():
if isinstance(obj, kvm_vm.VM):
obj.destroy()
-elif isinstance(obj, kvm_subprocess.kvm_spawn):
+elif isinstance(obj, kvm_subprocess.Spawn):
obj.close()
kvm_utils.dump_env(env, env_filename)
w.write("cleanup_done\n")
diff --git a/client/tests/kvm/kvm_subprocess.py
b/client/tests/kvm/kvm_subprocess.py
index c8caab2..e0723bb 100755
--- a/client/tests/kvm/kvm_subprocess.py
+++ b/client/tests/kvm/kvm_subprocess.py
@@ -292,12 +292,12 @@ def run_bg(command, termination_func=None,
output_func=None, output_prefix="",
@param timeout: Time duration (in seconds) to wait for the subprocess to
terminate before returning
-@return: A kvm_tail object.
+@return: A Tail object.
"""
-process = kvm_tail(command=command,
- termination_func=termination_func,
- output_func=output_func,
- output_prefix=output_prefix)
+process = Tail(command=command,
+ termination_func=termination_func,
+ output_func=output_func,
+ output_prefix=output_prefix)
end_time = time.time() + timeout
while time.time() < end_time and process.is_alive():
@@ -338,7 +338,7 @@ def run_fg(command, output_func=None, output_prefix="",
timeout=1.0):
return (status, output)
-class kvm_spawn:
+class Spawn:
"""
This class is used for spawning and controlling a child process.
@@ -350,7 +350,7 @@ class kvm_spawn:
The text file can be accessed at any time using get_output().
In addition, the server opens as many pipes as requested by the client and
writes the output to them.
-The pipes are requested and accessed by classes derived from kvm_spawn.
+The pipes are requested and accessed by classes derived from Spawn.
These pipes are referred to as "readers".
The server also receives input from the client and sends it to the child
process.
@@ -634,7 +634,7 @@ _thread_kill_requested = False
def kill_tail_threads():
"""
-Kill all kvm_tail threads.
+Kill all Tail threads.
After calling this function no new threads should be started.
"""
@@ -646,12 +646,12 @@ def kill_tail_threads():
_thread_kill_requested = False
-class kvm_tail(kvm_spawn):
+class Tail(Spawn):
"""
This class runs a child process in the background and sends its output in
real time, line-by-line, to a callback function.
-See kvm_spawn's docstring.
+See Spawn's docstring.
This class uses a single pipe reader to read data in real time from the
child process and report it to a given callback function.
@@ -692,10 +692,10 @@ class kvm_tail(kvm_spawn):
"""
# Add a reader and a close hook
self._add_reader("tail")
-self._add_close_hook(kvm_tail._join_thread)
+self._add_close_hook(Tail._join_thread)
# Init the superclass
-kvm_spawn.__init__(self, command, id, auto_close, echo, linesep)
+Spawn.__init__(self, command, id, auto_close, echo, linesep)
# Remember some attributes
self.termination_func = termination_func
@@ -711,11 +711,11 @@ class kvm_tail(kvm_spawn):
def __getinitarg
Re: [PATCH] x86/pvclock-xen: zero last_value on resume
On Tue, 2010-10-26 at 09:59 -0700, Jeremy Fitzhardinge wrote: > > If the guest domain has been suspend/resumed or migrated, then the > system clock backing the pvclock clocksource may revert to a smaller > value (ie, can be non-monotonic across the migration/save-restore). > Make sure we zero last_value in that case so that the domain > continues to see clock updates. > > [ I don't know if kvm needs an analogous fix or not. ] After migration, save/restore, etc, we issue an ioctl where we tell the host the last clock value. That (in theory) guarantees monotonicity. I am not opposed to this patch in any way, however. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST PATCH 3/5] KVM test: add utility functions start_windows_service() and stop_windows_service()
These utilities use sc to stop and start windows services. They're used by
whql_submission
and whql_client_install to stop or restart wttsvc on the client machine.
Resending because this seems never to have been committed.
Signed-off-by: Michael Goldish
---
client/tests/kvm/kvm_test_utils.py | 46
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/client/tests/kvm/kvm_test_utils.py
b/client/tests/kvm/kvm_test_utils.py
index c5f44b4..8d287b2 100644
--- a/client/tests/kvm/kvm_test_utils.py
+++ b/client/tests/kvm/kvm_test_utils.py
@@ -241,6 +241,52 @@ def migrate(vm, env=None, mig_timeout=3600,
mig_protocol="tcp",
return dest_vm
+def stop_windows_service(session, service, timeout=120):
+"""
+Stop a Windows service using sc.
+If the service is already stopped or is not installed, do nothing.
+
+@param service: The name of the service
+@param timeout: Time duration to wait for service to stop
+@raise error.TestError: Raised if the service can't be stopped
+"""
+end_time = time.time() + timeout
+while time.time() < end_time:
+o = session.get_command_output("sc stop %s" % service, timeout=60)
+# FAILED 1060 means the service isn't installed.
+# FAILED 1062 means the service hasn't been started.
+if re.search(r"\bFAILED (1060|1062)\b", o, re.I):
+break
+time.sleep(1)
+else:
+raise error.TestError("Could not stop service '%s'" % service)
+
+
+def start_windows_service(session, service, timeout=120):
+"""
+Start a Windows service using sc.
+If the service is already running, do nothing.
+If the service isn't installed, fail.
+
+@param service: The name of the service
+@param timeout: Time duration to wait for service to start
+@raise error.TestError: Raised if the service can't be started
+"""
+end_time = time.time() + timeout
+while time.time() < end_time:
+o = session.get_command_output("sc start %s" % service, timeout=60)
+# FAILED 1060 means the service isn't installed.
+if re.search(r"\bFAILED 1060\b", o, re.I):
+raise error.TestError("Could not start service '%s' "
+ "(service not installed)" % service)
+# FAILED 1056 means the service is already running.
+if re.search(r"\bFAILED 1056\b", o, re.I):
+break
+time.sleep(1)
+else:
+raise error.TestError("Could not start service '%s'" % service)
+
+
def get_time(session, time_command, time_filter_re, time_format):
"""
Return the host time and guest time. If the guest time cannot be fetched
--
1.5.5.6
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] KVM updates for the 2.6.37 merge window
On 10/26/2010 05:55 PM, Alexander Graf wrote: > Alex, if you want them in, please prepare backports for 2.6.36.1. Why backports for 2.6.36.1 when we're talking about 2.6.27? Most of them fix bugs introduced by the PV framework. I should have said 2.6.37-rc1, sorry. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST PATCH 2/5] KVM test: kvm_monitor.py: store attributes in QMPCmdError
For consistency with the exceptions in kvm_subprocess.
Signed-off-by: Michael Goldish
---
client/tests/kvm/kvm_monitor.py | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/client/tests/kvm/kvm_monitor.py b/client/tests/kvm/kvm_monitor.py
index e0365cd..7f5ddf8 100644
--- a/client/tests/kvm/kvm_monitor.py
+++ b/client/tests/kvm/kvm_monitor.py
@@ -38,9 +38,15 @@ class MonitorNotSupportedError(MonitorError):
class QMPCmdError(MonitorError):
+def __init__(self, cmd, qmp_args, data):
+MonitorError.__init__(self, cmd, qmp_args, data)
+self.cmd = cmd
+self.qmp_args = qmp_args
+self.data = data
+
def __str__(self):
-return ("QMP command '%s' failed (arguments: %r, error message: %r)" %
-tuple(self.args))
+return ("QMP command %r failed (arguments: %r, error message: %r)" %
+(self.cmd, self.qmp_args, self.data))
class Monitor:
--
1.5.5.6
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST PATCH 4/5] KVM test: kvm_subprocess: rename get_command_status_output() and friends
get_command_status_output() -> cmd_status_output() get_command_output() -> cmd_output() get_command_status() -> cmd_status() Signed-off-by: Michael Goldish --- client/tests/kvm/kvm_subprocess.py | 27 +-- client/tests/kvm/kvm_test_utils.py | 20 +++--- client/tests/kvm/tests/ethtool.py | 16 ++-- client/tests/kvm/tests/guest_s4.py |8 +++--- client/tests/kvm/tests/guest_test.py |3 +- client/tests/kvm/tests/iofuzz.py |2 +- client/tests/kvm/tests/ioquit.py |4 +- client/tests/kvm/tests/iozone_windows.py |4 +- client/tests/kvm/tests/ksm_overcommit.py |4 +- client/tests/kvm/tests/linux_s3.py |4 +- client/tests/kvm/tests/migration.py|7 ++--- client/tests/kvm/tests/multicast.py|8 +++--- client/tests/kvm/tests/netperf.py |4 +- client/tests/kvm/tests/nic_promisc.py |4 +- client/tests/kvm/tests/nicdriver_unload.py |4 +- client/tests/kvm/tests/pci_hotplug.py |6 ++-- client/tests/kvm/tests/physical_resources_check.py |2 +- client/tests/kvm/tests/timedrift.py|2 +- client/tests/kvm/tests/vlan.py | 11 +++ client/tests/kvm/tests/whql_client_install.py | 10 +++--- client/tests/kvm/tests/whql_submission.py |4 +- 21 files changed, 75 insertions(+), 79 deletions(-) diff --git a/client/tests/kvm/kvm_subprocess.py b/client/tests/kvm/kvm_subprocess.py index c92910c..c8caab2 100755 --- a/client/tests/kvm/kvm_subprocess.py +++ b/client/tests/kvm/kvm_subprocess.py @@ -1103,7 +1103,7 @@ class kvm_shell_session(kvm_expect): @param prompt: Regular expression describing the shell's prompt line. @param status_test_command: Command to be used for getting the last exit status of commands run inside the shell (used by -get_command_status_output() and friends). +cmd_status_output() and friends). """ # Init the superclass kvm_expect.__init__(self, command, id, auto_close, echo, linesep, @@ -1193,8 +1193,8 @@ class kvm_shell_session(kvm_expect): return o -def get_command_output(self, cmd, timeout=30.0, internal_timeout=None, - print_func=None): +def cmd_output(self, cmd, timeout=30.0, internal_timeout=None, + print_func=None): """ Send a command and return its output. @@ -1237,8 +1237,8 @@ class kvm_shell_session(kvm_expect): return remove_last_nonempty_line(remove_command_echo(o, cmd)) -def get_command_status_output(self, cmd, timeout=30.0, - internal_timeout=None, print_func=None): +def cmd_status_output(self, cmd, timeout=30.0, internal_timeout=None, + print_func=None): """ Send a command and return its exit status and output. @@ -1257,11 +1257,10 @@ class kvm_shell_session(kvm_expect): @raise ShellStatusError: Raised if the exit status cannot be obtained @raise ShellError: Raised if an unknown error occurs """ -o = self.get_command_output(cmd, timeout, internal_timeout, print_func) +o = self.cmd_output(cmd, timeout, internal_timeout, print_func) try: # Send the 'echo $?' (or equivalent) command to get the exit status -s = self.get_command_output(self.status_test_command, 10, -internal_timeout) +s = self.cmd_output(self.status_test_command, 10, internal_timeout) except ShellError: raise ShellStatusError(cmd, o) @@ -1273,8 +1272,8 @@ class kvm_shell_session(kvm_expect): raise ShellStatusError(cmd, o) -def get_command_status(self, cmd, timeout=30.0, internal_timeout=None, - print_func=None): +def cmd_status(self, cmd, timeout=30.0, internal_timeout=None, + print_func=None): """ Send a command and return its exit status. @@ -1292,8 +1291,8 @@ class kvm_shell_session(kvm_expect): @raise ShellStatusError: Raised if the exit status cannot be obtained @raise ShellError: Raised if an unknown error occurs """ -s, o = self.get_command_status_output(cmd, timeout, internal_timeout, - print_func) +s, o = self.cmd_status_output(cmd, timeout, internal_timeout, + print_func) return s @@ -1319,8 +1318,8 @@ class kvm_shell_session(kvm_expect): @raise ShellError: Raised if an unknown error occurs @raise ShellCmdError: Raised if the exit status is nonzero """ -s, o = self
Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks
On 10/26/2010 07:27 PM, Anthony Liguori wrote: Sorry, I don't follow your meaning. When I said "size is implied" I meant that the IOPort object has a separate function pointer for sizes 1, 2, and 4, so it ioport_register() doesn't need a size parameter. But I don't see how that relates to your comment. Yeah, I don't think it makes sense to combine "this is how to dispatch I/O" with "this is a region of I/O address space". Oh, so Blue meant the size of the region in ports, not the size of the individual ports. I think that putting the range length (but not base address) in the IOPort structure may make sense. I think an IORegion should contain an IOPort structure though. I think the name needs rethinking. Maybe: struct PortIOHandler; struct MemoryIOHandler; Why two types? I think some devices use PIO on a PC and MMIO on other architectures. Sharing the type would allow sharing code. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks
On 10/26/2010 12:18 PM, Avi Kivity wrote:
On 10/26/2010 05:09 PM, Blue Swirl wrote:
On Tue, Oct 26, 2010 at 8:05 AM, Avi Kivity wrote:
>On 10/25/2010 08:38 PM, Blue Swirl wrote:
>>
>> >
>> >I don't really see why we need registration;
cpu_register_io() takes
>> >function pointers, a size, and an opaque, and gives an
integer handle
>> > in
>> >return. With the IOPort object approach, you set up the
IOPort with
>> >function pointers, size is implied, and the opaque is derived
using
>> >container_of(); the handle is simply the address of the object.
>>
>> With the handle, we can separate setting up the structures at device
>> level, and mapping the object using only the handle at bus or other
>> higher level. Can this be done with the object approach?
>
> I believe so. The handle is simply an indirect pointer, no?
Yes, but then the object should also contain size information. That
should not be needed for mapping at higher level.
Sorry, I don't follow your meaning.
When I said "size is implied" I meant that the IOPort object has a
separate function pointer for sizes 1, 2, and 4, so it
ioport_register() doesn't need a size parameter. But I don't see how
that relates to your comment.
Yeah, I don't think it makes sense to combine "this is how to dispatch
I/O" with "this is a region of I/O address space".
I think an IORegion should contain an IOPort structure though. I think
the name needs rethinking.
Maybe:
struct PortIOHandler;
struct MemoryIOHandler;
And it would be good to add a memory callback to this series too.
Regards,
Anthony Liguori
>> The purpose of that patch series was to perform the separation
for PCI
>> BARs. I wasn't so happy with the series, so I never pushed.
>
> In fact I think an IOPort is even more suitable; if we need
additional
> attributes we can use a derived object:
>
> struct PCIIOPort {
> IOPort ioport;
> /* additional fields */
> };
One issue with my series was that it would be great if the devices
just had some BAR structures (used by PCI layer to map the devices)
inside PCI/qdev structures, but I invented that too late. Maybe this
can be addressed in your design?
It looks to be orthogonal. It would be great to have a BAR object;
that object can then use your API, my API, or the existing API.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks
On 10/26/2010 05:09 PM, Blue Swirl wrote:
On Tue, Oct 26, 2010 at 8:05 AM, Avi Kivity wrote:
>On 10/25/2010 08:38 PM, Blue Swirl wrote:
>>
>> >
>> >I don't really see why we need registration; cpu_register_io() takes
>> >function pointers, a size, and an opaque, and gives an integer handle
>> > in
>> >return. With the IOPort object approach, you set up the IOPort with
>> >function pointers, size is implied, and the opaque is derived using
>> >container_of(); the handle is simply the address of the object.
>>
>> With the handle, we can separate setting up the structures at device
>> level, and mapping the object using only the handle at bus or other
>> higher level. Can this be done with the object approach?
>
> I believe so. The handle is simply an indirect pointer, no?
Yes, but then the object should also contain size information. That
should not be needed for mapping at higher level.
Sorry, I don't follow your meaning.
When I said "size is implied" I meant that the IOPort object has a
separate function pointer for sizes 1, 2, and 4, so it ioport_register()
doesn't need a size parameter. But I don't see how that relates to your
comment.
>> The purpose of that patch series was to perform the separation for PCI
>> BARs. I wasn't so happy with the series, so I never pushed.
>
> In fact I think an IOPort is even more suitable; if we need additional
> attributes we can use a derived object:
>
> struct PCIIOPort {
> IOPort ioport;
> /* additional fields */
> };
One issue with my series was that it would be great if the devices
just had some BAR structures (used by PCI layer to map the devices)
inside PCI/qdev structures, but I invented that too late. Maybe this
can be addressed in your design?
It looks to be orthogonal. It would be great to have a BAR object; that
object can then use your API, my API, or the existing API.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] Add a global synchronization point for pvclock
On 10/26/2010 01:14 AM, Avi Kivity wrote: > On 10/26/2010 01:30 AM, Jeremy Fitzhardinge wrote: >> Unfortunately this is breaking Xen save/restore: if you restore on a >> host which was booted more recently than the save host, causing the >> system time to be smaller. The effect is that the domain's time leaps >> forward to a fixed point, and stays there until the host catches up to >> the source host... > > Shouldn't save/restore also save the timebase? Xen doesn't guarantee the system time is monotonic across those kinds of events. The domain could maintain its own offset to maintain an illusion of monotonicity, but I think its simpler to just zero last_value on resume. J -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c
> Not unless they are actively known to break. People get huffy about it Well they do -- i just found out. > because even if it is known to have problems it doesn't break *their* > particular configuration. I'm getting to be of the opinion that people > who compile modern kernels with ancient compilers and expect it to work > are suffering from some particular kind of insanity -- it's nothing the > distros do. The only exception are embedded people who compile with the > latest 3.4 gcc; they have explained they do so because newer gccs have > too many dependencies (the actual compiler, not the generated code) and > for speed. At least in the old days the main reason for gcc 3 was build speed. AKPM and some others used to be fond of that. 3.x is apparently much faster than 4.x -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86/pvclock-xen: zero last_value on resume
If the guest domain has been suspend/resumed or migrated, then the
system clock backing the pvclock clocksource may revert to a smaller
value (ie, can be non-monotonic across the migration/save-restore).
Make sure we zero last_value in that case so that the domain
continues to see clock updates.
[ I don't know if kvm needs an analogous fix or not. ]
Signed-off-by: Jeremy Fitzhardinge
Cc: Stable Kernel
Reported-by: Eelco Dolstra
Reported-by: Olivier Hanesse
Bisected-by: Cédric Schieli
Tested-by: Cédric Schieli
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index cd02f32..6226870 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -11,5 +11,6 @@ unsigned long pvclock_tsc_khz(struct pvclock_vcpu_time_info
*src);
void pvclock_read_wallclock(struct pvclock_wall_clock *wall,
struct pvclock_vcpu_time_info *vcpu,
struct timespec *ts);
+void pvclock_resume(void);
#endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 239427c..a4f07c1 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -120,6 +120,11 @@ unsigned long pvclock_tsc_khz(struct
pvclock_vcpu_time_info *src)
static atomic64_t last_value = ATOMIC64_INIT(0);
+void pvclock_resume(void)
+{
+ atomic64_set(&last_value, 0);
+}
+
cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
{
struct pvclock_shadow_time shadow;
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index b2bb5aa..5da5e53 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -426,6 +426,8 @@ void xen_timer_resume(void)
{
int cpu;
+ pvclock_resume();
+
if (xen_clockevent != &xen_vcpuop_clockevent)
return;
From 29acbb4e1d93e719250648db1ce8c7a24144fd86 Mon Sep 17 00:00:00 2001
From: Jeremy Fitzhardinge
Date: Mon, 25 Oct 2010 16:53:46 -0700
Subject: [PATCH] x86/pvclock: zero last_value on resume
If the guest domain has been suspend/resumed or migrated, then the
system clock backing the pvclock clocksource may revert to a smaller
value (ie, can be non-monotonic across the migration/save-restore).
Make sure we zero last_value in that case so that the domain
continues to see clock updates.
Signed-off-by: Jeremy Fitzhardinge
Cc: Stable Kernel
Reported-by: Eelco Dolstra
Reported-by: Olivier Hanesse
Bisected-by: Cédric Schieli
Tested-by: Cédric Schieli
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index cd02f32..6226870 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -11,5 +11,6 @@ unsigned long pvclock_tsc_khz(struct pvclock_vcpu_time_info
*src);
void pvclock_read_wallclock(struct pvclock_wall_clock *wall,
struct pvclock_vcpu_time_info *vcpu,
struct timespec *ts);
+void pvclock_resume(void);
#endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 239427c..a4f07c1 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -120,6 +120,11 @@ unsigned long pvclock_tsc_khz(struct
pvclock_vcpu_time_info *src)
static atomic64_t last_value = ATOMIC64_INIT(0);
+void pvclock_resume(void)
+{
+ atomic64_set(&last_value, 0);
+}
+
cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
{
struct pvclock_shadow_time shadow;
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index b2bb5aa..5da5e53 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -426,6 +426,8 @@ void xen_timer_resume(void)
{
int cpu;
+ pvclock_resume();
+
if (xen_clockevent != &xen_vcpuop_clockevent)
return;
Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c
On 10/26/2010 09:37 AM, Andi Kleen wrote: >> We have said 3.4 minimum for x86 for a long time now, and have an RFC > > Ok makes sense. I thought it was still at 3.3. I should retire > this 3.3 fossil anyways, it's really only for old compat testing. > > I don't remember seeing a warning -- aren't there supposed to be warnings > for unsupported compilers? > Not unless they are actively known to break. People get huffy about it because even if it is known to have problems it doesn't break *their* particular configuration. I'm getting to be of the opinion that people who compile modern kernels with ancient compilers and expect it to work are suffering from some particular kind of insanity -- it's nothing the distros do. The only exception are embedded people who compile with the latest 3.4 gcc; they have explained they do so because newer gccs have too many dependencies (the actual compiler, not the generated code) and for speed. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM devices assignment; PCIe AER?
Chris, Michael et al. Part of the project I'm working on, we are looking at extending the device assignment capabilities to provide support for PCIe AER. Ideally, the host would register for AER (for every assigned devices) and pass them up to Qemu. As of now, one of the problem is that KVM is not a driver for the assigned devices. I've seen Chris's slides from KVM conf 2010 but I haven't seen any patches or discussion on that topic... On another front, I've seen the work from Michael around 'uio_pci_generic' and some of his comments: " It's expected that more features of interest to virtualization will be added to this driver in the future. Possibilities are: mmap for device resources, MSI/MSI-X, eventfd (to interface with kvm), iommu." I think that extending 'uio_pci_generic' to support AER is relatively straight forward (assuming eventfd support from UIO). Any thought? thanks, -Etienne -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c
> We have said 3.4 minimum for x86 for a long time now, and have an RFC Ok makes sense. I thought it was still at 3.3. I should retire this 3.3 fossil anyways, it's really only for old compat testing. I don't remember seeing a warning -- aren't there supposed to be warnings for unsupported compilers? -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] KVM updates for the 2.6.37 merge window
On 25.10.2010, at 09:59, Avi Kivity wrote: > On 10/25/2010 06:49 PM, Scott Wood wrote: >> On Sun, 24 Oct 2010 15:29:12 +0200 >> Avi Kivity wrote: >> >> >Linus, the repository and branch >> > >> > git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.37 >> > >> > contains the kvm updates for the 2.6.37 merge window. Major changes >> > this time around include powerpc paravirtualization, a virtual tsc >> > rework, and exposing npt to the guest for fast nested virtualization. >> > Please pull. >> >> How about these patches which are in kvm.git/next but not >> kvm-updates/2.6.37? >> >> PPC: KVM: Book E doesn't have __end_interrupts. >> KVM: PPC: e500: Call kvm_vcpu_uninit() before kvmppc_e500_tlb_uninit() >> KVM: PPC: BookE: fix sleep with interrupts disabled >> KVM: PPC: BookE: Load the lower half of MSR >> > > Alex, if you want them in, please prepare backports for 2.6.36.1. Why backports for 2.6.36.1 when we're talking about 2.6.27? Most of them fix bugs introduced by the PV framework. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks
On Tue, Oct 26, 2010 at 8:05 AM, Avi Kivity wrote:
> On 10/25/2010 08:38 PM, Blue Swirl wrote:
>>
>> >
>> > I don't really see why we need registration; cpu_register_io() takes
>> > function pointers, a size, and an opaque, and gives an integer handle
>> > in
>> > return. With the IOPort object approach, you set up the IOPort with
>> > function pointers, size is implied, and the opaque is derived using
>> > container_of(); the handle is simply the address of the object.
>>
>> With the handle, we can separate setting up the structures at device
>> level, and mapping the object using only the handle at bus or other
>> higher level. Can this be done with the object approach?
>
> I believe so. The handle is simply an indirect pointer, no?
Yes, but then the object should also contain size information. That
should not be needed for mapping at higher level.
>> The purpose of that patch series was to perform the separation for PCI
>> BARs. I wasn't so happy with the series, so I never pushed.
>
> In fact I think an IOPort is even more suitable; if we need additional
> attributes we can use a derived object:
>
> struct PCIIOPort {
> IOPort ioport;
> /* additional fields */
> };
One issue with my series was that it would be great if the devices
just had some BAR structures (used by PCI layer to map the devices)
inside PCI/qdev structures, but I invented that too late. Maybe this
can be addressed in your design?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Page Eviction Algorithm
>>> >>> Can you please suggest me something that would add value to KVM? >>> >> >> O(1) write protection (on the TODO page) is interesting and important. It's >> difficult, so you may want to start with O(1) invalidation. > > I am not sure if I can understand what exactly is a MMU invalidation. > Is it cache invalidation or TLB invalidation? Can you please > elaborate. I am really sorry if I am asking a silly question. Does this MMU invalidation has to do something with the EPT (Extended Page Table) and instruction INVEPT? Please clarify. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM call minutes for Oct 26
Guest Agents - need to get to guest userspace for many actions - virtio for userspace - host backend needs to terminate in QEMU - portable across guest OS's - virt-agent - bi-directional RPC (XML-RPC just since it's easy) - cmd: shutdown, reboot, dmesg, execute command, read/write file - query guest type - Matahari - consolidate agent proliferation - w/ or w/out networking (virtio-serial is fine) - may or may not have access to host - using amqp - single transport - use of qpid (C++, not C friendly) - put qemu bits in library and wrap (similar to libvirt, netcf, etc) - e.g. shutdown, where does it live? - ACPI shutdown can trigger dbus, dialog, etc. - can already do ACPI, agent is for direct "shutdown -h now" - is there an async notification on shutdown (know it's been sucessful) - perhaps another library like libsysconfig - openvmtools - useful as reference, GPL (requires copyright assignment) - uses PIO (or socket) 0.13.1 - vmmouse is broken - assertion failure in block layer - just qemu-img: https://bugzilla.redhat.com/show_bug.cgi?id=646538 - patch posted, thanks Stefan - hotplug fixes - fix for seabios SCI level triggered (broken host initiated powerdown on FreeBSD) - regression <-- any regression needs to be considered seriously - was planning to move to 0.6.1 (vs. latest git snapshot) - kevin indicated ok with stable/tagging/branch for seabios bootindex patch series - qdev name vs specific name - fine for seabios interface - migration needs stable address too - worth holding up series for this? - one more try, then fallback to plan b (new callback) migration issues - keep using network after VM has stopped - sent hacky patch for virtio-net, but need a generic sol'n - virtio-block flushes after stop - need a similar stop/flush for other devices - unclear how anything is running w/out getting back to main loop - happening after migration completes networking interfaces - old vlan vs new netdev...be nice to finish off and simply internal interfaces -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qcow2: Fix segfault when qcow2 preallocate fails
On Tue, Oct 26, 2010 at 2:48 PM, Kevin Wolf wrote: > Am 26.10.2010 15:23, schrieb Stefan Hajnoczi: >> When an image is created with -o preallocate, ensure that we only call >> preallocate() if the image was indeed opened successfully. Also use >> bdrv_delete() instead of bdrv_close() to avoid leaking the >> BlockDriverState structure. >> >> This fixes the segfault reported at >> https://bugzilla.redhat.com/show_bug.cgi?id=646538. >> >> Signed-off-by: Stefan Hajnoczi > > Looks good for stable-0.13. In master we'll have the new qcow_create2 > implementation as soon as Anthony pulls, so it doesn't apply there. I forgot about that :). Thanks Kevin. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qcow2: Fix segfault when qcow2 preallocate fails
Am 26.10.2010 15:23, schrieb Stefan Hajnoczi: > When an image is created with -o preallocate, ensure that we only call > preallocate() if the image was indeed opened successfully. Also use > bdrv_delete() instead of bdrv_close() to avoid leaking the > BlockDriverState structure. > > This fixes the segfault reported at > https://bugzilla.redhat.com/show_bug.cgi?id=646538. > > Signed-off-by: Stefan Hajnoczi Looks good for stable-0.13. In master we'll have the new qcow_create2 implementation as soon as Anthony pulls, so it doesn't apply there. Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Page Eviction Algorithm
On Tue, Oct 26, 2010 at 2:07 PM, Avi Kivity wrote: > On 10/26/2010 12:42 PM, Prasad Joshi wrote: >> >> Thanks a lot for your reply. >> >> On Tue, Oct 26, 2010 at 11:31 AM, Avi Kivity wrote: >> > On 10/26/2010 11:19 AM, Prasad Joshi wrote: >> >> >> >> Hi All, >> >> >> >> I was just going over TODO list on KVM page. In MMU related TODO I saw >> >> only page eviction algorithm currently implemented is FIFO. >> >> >> >> Is it really the case? >> > >> > Yes. >> > >> >> If yes I would like to work on it. Can someone >> >> let me know the place where the FIFO code is implemented? >> > >> > Look at the code that touches mmu_active_list. >> > >> > FWIW improving the algorithm is not critically important. It's rare >> > that >> > mmu shadow pages need to be evicted. >> >> I would be doing a University project on Virtualization. I would like >> to work on Linux kernel and KVM. I was looking over the TODO list on >> KVM wiki. >> >> Can you please suggest me something that would add value to KVM? >> > > O(1) write protection (on the TODO page) is interesting and important. It's > difficult, so you may want to start with O(1) invalidation. I am not sure if I can understand what exactly is a MMU invalidation. Is it cache invalidation or TLB invalidation? Can you please elaborate. I am really sorry if I am asking a silly question. > > -- > error compiling committee.c: too many arguments to function > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qcow2: Fix segfault when qcow2 preallocate fails
When an image is created with -o preallocate, ensure that we only call
preallocate() if the image was indeed opened successfully. Also use
bdrv_delete() instead of bdrv_close() to avoid leaking the
BlockDriverState structure.
This fixes the segfault reported at
https://bugzilla.redhat.com/show_bug.cgi?id=646538.
Signed-off-by: Stefan Hajnoczi
---
Here's a fix for the segfault.
block/qcow2.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index ee3481b..0fceb0d 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1059,9 +1059,11 @@ exit:
BlockDriverState *bs;
BlockDriver *drv = bdrv_find_format("qcow2");
bs = bdrv_new("");
-bdrv_open(bs, filename, BDRV_O_CACHE_WB | BDRV_O_RDWR, drv);
-ret = preallocate(bs);
-bdrv_close(bs);
+ret = bdrv_open(bs, filename, BDRV_O_CACHE_WB | BDRV_O_RDWR, drv);
+if (ret == 0) {
+ret = preallocate(bs);
+}
+bdrv_delete(bs);
}
return ret;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Oct 26
On Tue, Oct 26, 2010 at 08:22:38AM -0500, Anthony Liguori wrote: > On 10/26/2010 08:04 AM, Avi Kivity wrote: > > On 10/26/2010 02:49 PM, Anthony Liguori wrote: > >>On 10/26/2010 03:20 AM, Avi Kivity wrote: > >>> On 10/25/2010 09:51 PM, Juan Quintela wrote: > Please send in any agenda items you are interested in covering. > > >>> > >>>0.13.1 > >>> > >>>At least two fatal issues: > >>>- vmmouse is broken > >>>- assertion failure in block layer > >> > >>There's actually a fair bit. I'm hoping to also get the hotplug > >>fixes because tose are pretty important IMHO. I don't want to > >>wait too long though. > > > >Also, a new seabios for the SCI level triggered fix. > > You mean: > > commit 6d5a2172f2b76900572107868ec080400c4f615d > Author: Kevin O'Connor > Date: Wed Oct 20 21:59:11 2010 -0400 > > mark irq9 active high in DSDT > > In PIIX4 SCI (irq9) is active high. Seabios marks it so in interrupt > override table, but some OSes (FreeBSD) require the same information to > be present in DSDT too. Make it so. > > Signed-off-by: Gleb Natapov > > If so, what's the impact of it not being there? I wanted to stick Power down from qemu monitor does not work for FreeBSD. > to 0.6.1 for stable-0.13, updating to a git snapshot is going to > pull a lot of things in that would be better to avoid for stable. > We can talk to Kevin about a stable branch but I'd like to > understand what the real impact here is first. > > Regards, > > Anthony Liguori > > >> > >>What's the assertion in the block layer? > > > >https://bugzilla.redhat.com/show_bug.cgi?id=646538 > > > >This is qemu-img, so maybe not so critical. I confused this with > >a runtime assertion failure in the block layer, for which a fix > >was merged post rc3. > > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Oct 26
On 10/26/2010 08:04 AM, Avi Kivity wrote: On 10/26/2010 02:49 PM, Anthony Liguori wrote: On 10/26/2010 03:20 AM, Avi Kivity wrote: On 10/25/2010 09:51 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.13.1 At least two fatal issues: - vmmouse is broken - assertion failure in block layer There's actually a fair bit. I'm hoping to also get the hotplug fixes because tose are pretty important IMHO. I don't want to wait too long though. Also, a new seabios for the SCI level triggered fix. You mean: commit 6d5a2172f2b76900572107868ec080400c4f615d Author: Kevin O'Connor Date: Wed Oct 20 21:59:11 2010 -0400 mark irq9 active high in DSDT In PIIX4 SCI (irq9) is active high. Seabios marks it so in interrupt override table, but some OSes (FreeBSD) require the same information to be present in DSDT too. Make it so. Signed-off-by: Gleb Natapov If so, what's the impact of it not being there? I wanted to stick to 0.6.1 for stable-0.13, updating to a git snapshot is going to pull a lot of things in that would be better to avoid for stable. We can talk to Kevin about a stable branch but I'd like to understand what the real impact here is first. Regards, Anthony Liguori What's the assertion in the block layer? https://bugzilla.redhat.com/show_bug.cgi?id=646538 This is qemu-img, so maybe not so critical. I confused this with a runtime assertion failure in the block layer, for which a fix was merged post rc3. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
recent nested-virtualization publications
It appears that recently there is growing interest in nested virtualization. A few days ago, VMWare released a technical report, titled "Bounding the Running Time of Interrupt and Exception Forwarding in Recursive Virtualization for the x86 Architecture", available at http://www.vmware.com.mx/files/pdf/partners/academic/hh.pdf This report discusses why nested virtualization is important, and estimates the performance of multiple levels of nesting. They show that the interrupt handling time is exponential in the number of levels, but propose hardware modifications which could make it linear. Their results are based on simulations, not on an actual implementation of nested virtualization in VMWare: They say that "current hardware is not performant enough for real implementation", and that "The design described in this paper is not in any VMware shipped product". As I wrote in a previous email, earlier this month we published our paper on nested VMX in KVM, "The Turtles Project: Design and Implementation of Nested Virtualization". The paper was not only accepted to the Usenix Symposium on Operating Systems Design and Implementation (OSDI), it was even chosen "Jay Lepreau Best Paper". Among other things, this shows that the program committee and reviewers found nested virtualization to be an important research topic. A few months ago, Olivier Berghmans from Antwerp University published an MSc thesis titled "Nesting Virtual Machines in Virtualization Test Framework" in which he, again, explained why nested virtualization is important, and how it can be done without new hardware or software (e.g., one option is to run a software-only hypervisor on a hardware-assited hypervisor, but he surveys many other options), and compared many different options. ScaleMP announced in May "VM on VM" (see http://www.scalemp.com/VMonVM), a feature which allows to run a hypervisor on top of their underlying hypervisor. I haven't seen any details published on what exactly they did, or how. In April, Nested SVM and Nested VMX patches (for hardware-assisted virtualization) were also sent to Xen. I am not sure what is the status of these patches. I put copies of all above mentioned documents (in case there's difficulty in finding them), in http://www.math.technion.ac.il/~nyh/nested/ -- Nadav Har'El n...@il.ibm.com +972-4-829-6326 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Oct 26
On Mon, Oct 25, 2010 at 09:51:36PM +0200, Juan Quintela wrote: > > Please send in any agenda items you are interested in covering. > bootindex patch series. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Autotest] [KVM-AUTOTEST PATCH 7/7] [RFC] KVM test: migrate_cancel: allow for alternative spellings of 'cancelled'
On Sun, 2010-10-24 at 13:01 +0200, Michael Goldish wrote:
> Is there any chance someone will decide to switch over to the American
> spelling?
This is mainly harmless. Even if the switch won't happen, this is
absolutely fine, thanks!
> Signed-off-by: Michael Goldish
> ---
> client/tests/kvm/kvm_test_utils.py |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/client/tests/kvm/kvm_test_utils.py
> b/client/tests/kvm/kvm_test_utils.py
> index 1bb8920..a3b182b 100644
> --- a/client/tests/kvm/kvm_test_utils.py
> +++ b/client/tests/kvm/kvm_test_utils.py
> @@ -157,9 +157,11 @@ def migrate(vm, env=None, mig_timeout=3600,
> mig_protocol="tcp",
> def mig_cancelled():
> o = vm.monitor.info("migrate")
> if isinstance(o, str):
> -return "Migration status: cancelled" in o
> +return ("Migration status: cancelled" in o or
> +"Migration status: canceled" in o)
> else:
> -return o.get("status") == "cancelled"
> +return (o.get("status") == "cancelled" or
> +o.get("status") == "canceled")
>
> def wait_for_migration():
> if not kvm_utils.wait_for(mig_finished, mig_timeout, 2, 2,
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Page Eviction Algorithm
On 10/26/2010 12:42 PM, Prasad Joshi wrote: Thanks a lot for your reply. On Tue, Oct 26, 2010 at 11:31 AM, Avi Kivity wrote: >On 10/26/2010 11:19 AM, Prasad Joshi wrote: >> >> Hi All, >> >> I was just going over TODO list on KVM page. In MMU related TODO I saw >> only page eviction algorithm currently implemented is FIFO. >> >> Is it really the case? > > Yes. > >> If yes I would like to work on it. Can someone >> let me know the place where the FIFO code is implemented? > > Look at the code that touches mmu_active_list. > > FWIW improving the algorithm is not critically important. It's rare that > mmu shadow pages need to be evicted. I would be doing a University project on Virtualization. I would like to work on Linux kernel and KVM. I was looking over the TODO list on KVM wiki. Can you please suggest me something that would add value to KVM? O(1) write protection (on the TODO page) is interesting and important. It's difficult, so you may want to start with O(1) invalidation. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Oct 26
On 10/26/2010 02:49 PM, Anthony Liguori wrote: On 10/26/2010 03:20 AM, Avi Kivity wrote: On 10/25/2010 09:51 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.13.1 At least two fatal issues: - vmmouse is broken - assertion failure in block layer There's actually a fair bit. I'm hoping to also get the hotplug fixes because tose are pretty important IMHO. I don't want to wait too long though. Also, a new seabios for the SCI level triggered fix. What's the assertion in the block layer? https://bugzilla.redhat.com/show_bug.cgi?id=646538 This is qemu-img, so maybe not so critical. I confused this with a runtime assertion failure in the block layer, for which a fix was merged post rc3. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH 3/7] [RFC] KVM test: remove all code related to the old MAC address pool method
On Sun, 2010-10-24 at 13:01 +0200, Michael Goldish wrote:
> This patch removes all code related to the old manual method
> (address_pools.cfg).
>
> Note that now running in TAP mode requires an external DHCP server that
> accepts
> *any* MAC address, because MAC addresses are randomly generated and cannot be
> manually configured.
Yes, this patch looks good. I don't think there are much DHCP servers
that do not accept any MAC address. It might be good to document this
information on the wiki though.
> Signed-off-by: Michael Goldish
> ---
> client/tests/kvm/kvm_utils.py | 159
>
> client/tests/kvm/kvm_vm.py | 34 ++---
> client/tests/kvm/tests/physical_resources_check.py | 11 +-
> client/tests/kvm/tests/stress_boot.py |3 -
> client/tests/kvm/tests_base.cfg.sample |2 -
> 5 files changed, 16 insertions(+), 193 deletions(-)
>
> diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
> index 778637d..f749f8d 100644
> --- a/client/tests/kvm/kvm_utils.py
> +++ b/client/tests/kvm/kvm_utils.py
> @@ -203,165 +203,6 @@ def get_mac_address(vm_instance, nic_index):
> return mac
>
>
> -def mac_str_to_int(addr):
> -"""
> -Convert MAC address string to integer.
> -
> -@param addr: String representing the MAC address.
> -"""
> -return sum(int(s, 16) * 256 ** i
> - for i, s in enumerate(reversed(addr.split(":"
> -
> -
> -def mac_int_to_str(addr):
> -"""
> -Convert MAC address integer to string.
> -
> -@param addr: Integer representing the MAC address.
> -"""
> -return ":".join("%02x" % (addr >> 8 * i & 0xFF)
> -for i in reversed(range(6)))
> -
> -
> -def ip_str_to_int(addr):
> -"""
> -Convert IP address string to integer.
> -
> -@param addr: String representing the IP address.
> -"""
> -return sum(int(s) * 256 ** i
> - for i, s in enumerate(reversed(addr.split("."
> -
> -
> -def ip_int_to_str(addr):
> -"""
> -Convert IP address integer to string.
> -
> -@param addr: Integer representing the IP address.
> -"""
> -return ".".join(str(addr >> 8 * i & 0xFF)
> -for i in reversed(range(4)))
> -
> -
> -def offset_mac(base, offset):
> -"""
> -Add offset to a given MAC address.
> -
> -@param base: String representing a MAC address.
> -@param offset: Offset to add to base (integer)
> -@return: A string representing the offset MAC address.
> -"""
> -return mac_int_to_str(mac_str_to_int(base) + offset)
> -
> -
> -def offset_ip(base, offset):
> -"""
> -Add offset to a given IP address.
> -
> -@param base: String representing an IP address.
> -@param offset: Offset to add to base (integer)
> -@return: A string representing the offset IP address.
> -"""
> -return ip_int_to_str(ip_str_to_int(base) + offset)
> -
> -
> -def get_mac_ip_pair_from_dict(dict):
> -"""
> -Fetch a MAC-IP address pair from dict and return it.
> -
> -The parameters in dict are expected to conform to a certain syntax.
> -Typical usage may be:
> -
> -address_ranges = r1 r2 r3
> -
> -address_range_base_mac_r1 = 55:44:33:22:11:00
> -address_range_base_ip_r1 = 10.0.0.0
> -address_range_size_r1 = 16
> -
> -address_range_base_mac_r2 = 55:44:33:22:11:40
> -address_range_base_ip_r2 = 10.0.0.60
> -address_range_size_r2 = 25
> -
> -address_range_base_mac_r3 = 55:44:33:22:12:10
> -address_range_base_ip_r3 = 10.0.1.20
> -address_range_size_r3 = 230
> -
> -address_index = 0
> -
> -All parameters except address_index specify a MAC-IP address pool. The
> -pool consists of several MAC-IP address ranges.
> -address_index specified the index of the desired MAC-IP pair from the
> pool.
> -
> -@param dict: The dictionary from which to fetch the addresses.
> -"""
> -index = int(dict.get("address_index", 0))
> -for mac_range_name in get_sub_dict_names(dict, "address_ranges"):
> -mac_range_params = get_sub_dict(dict, mac_range_name)
> -mac_base = mac_range_params.get("address_range_base_mac")
> -ip_base = mac_range_params.get("address_range_base_ip")
> -size = int(mac_range_params.get("address_range_size", 1))
> -if index < size:
> -return (mac_base and offset_mac(mac_base, index),
> -ip_base and offset_ip(ip_base, index))
> -index -= size
> -return (None, None)
> -
> -
> -def get_sub_pool(dict, piece, num_pieces):
> -"""
> -Split a MAC-IP pool and return a single requested piece.
> -
> -For example, get_sub_pool(dict, 0, 3) will split the pool in 3 pieces and
> -return a dict representing the first piece.
> -
> -@param dict: A dict that contains pool parameters.
> -@param piece: The index of the requested piece. Should range from 0 to
> -n
Re: KVM call agenda for Oct 26
On 10/26/2010 03:20 AM, Avi Kivity wrote: On 10/25/2010 09:51 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.13.1 At least two fatal issues: - vmmouse is broken - assertion failure in block layer There's actually a fair bit. I'm hoping to also get the hotplug fixes because tose are pretty important IMHO. I don't want to wait too long though. What's the assertion in the block layer? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
On Tue, Oct 26, 2010 at 03:31:39PM +0530, Krishna Kumar2 wrote: > > "Michael S. Tsirkin" > > > > On Tue, Oct 26, 2010 at 02:38:53PM +0530, Krishna Kumar2 wrote: > > > Results for UDP BW tests (unidirectional, sum across > > > 3 iterations, each iteration of 45 seconds, default > > > netperf, vhosts bound to cpus 0-3; no other tuning): > > > > Is binding vhost threads to CPUs really required? > > What happens if we let the scheduler do its job? > > Nothing drastic, I remember BW% and SD% both improved a > bit as a result of binding. If there's a significant improvement this would mean that we need to rethink the vhost-net interaction with the scheduler. > I started binding vhost thread > after Avi suggested it in response to my v1 patch (he > suggested some more that I haven't done), and have been > doing only this tuning ever since. This is part of his > mail for the tuning: > > > vhost: > > thread #0: CPU0 > > thread #1: CPU1 > > thread #2: CPU2 > > thread #3: CPU3 > > I simply bound each thread to CPU0-3 instead. > > Thanks, > > - KK -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/14] drivers/vhost/vhost.c: delete double assignment
On Tue, Oct 26, 2010 at 12:25:32PM +0200, Julia Lawall wrote: > From: Julia Lawall > > Delete successive assignments to the same location. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression i; > @@ > > *i = ...; > i = ...; > // > > Signed-off-by: Julia Lawall Thanks, applied. > --- > drivers/vhost/vhost.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c > index 94701ff..ed27727 100644 > --- a/drivers/vhost/vhost.c > +++ b/drivers/vhost/vhost.c > @@ -157,7 +157,6 @@ static void vhost_vq_reset(struct vhost_dev *dev, > vq->avail_idx = 0; > vq->last_used_idx = 0; > vq->used_flags = 0; > - vq->used_flags = 0; > vq->log_used = false; > vq->log_addr = -1ull; > vq->vhost_hlen = 0; -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] Add a global synchronization point for pvclock
On Tue, 2010-10-26 at 10:14 +0200, Avi Kivity wrote: > On 10/26/2010 01:30 AM, Jeremy Fitzhardinge wrote: > > Unfortunately this is breaking Xen save/restore: if you restore on a > > host which was booted more recently than the save host, causing the > > system time to be smaller. The effect is that the domain's time leaps > > forward to a fixed point, and stays there until the host catches up to > > the source host... > > Shouldn't save/restore also save the timebase? > > > I guess last_time needs to be reset on this type of event. I guess the > > cleanest way would be for pvclock.c to register a sysdev suspend/resume > > handler. > > Should be for Xen only; kvm save/restore doesn't involve the guest. the suspend/resume path do adjust the time base. Maybe something similar should be done ? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Page Eviction Algorithm
Thanks a lot for your reply. On Tue, Oct 26, 2010 at 11:31 AM, Avi Kivity wrote: > On 10/26/2010 11:19 AM, Prasad Joshi wrote: >> >> Hi All, >> >> I was just going over TODO list on KVM page. In MMU related TODO I saw >> only page eviction algorithm currently implemented is FIFO. >> >> Is it really the case? > > Yes. > >> If yes I would like to work on it. Can someone >> let me know the place where the FIFO code is implemented? > > Look at the code that touches mmu_active_list. > > FWIW improving the algorithm is not critically important. It's rare that > mmu shadow pages need to be evicted. I would be doing a University project on Virtualization. I would like to work on Linux kernel and KVM. I was looking over the TODO list on KVM wiki. Can you please suggest me something that would add value to KVM? > > -- > error compiling committee.c: too many arguments to function > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Page Eviction Algorithm
On 10/26/2010 11:19 AM, Prasad Joshi wrote: Hi All, I was just going over TODO list on KVM page. In MMU related TODO I saw only page eviction algorithm currently implemented is FIFO. Is it really the case? Yes. If yes I would like to work on it. Can someone let me know the place where the FIFO code is implemented? Look at the code that touches mmu_active_list. FWIW improving the algorithm is not critically important. It's rare that mmu shadow pages need to be evicted. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/14] drivers/vhost/vhost.c: delete double assignment
From: Julia Lawall Delete successive assignments to the same location. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression i; @@ *i = ...; i = ...; // Signed-off-by: Julia Lawall --- drivers/vhost/vhost.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 94701ff..ed27727 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -157,7 +157,6 @@ static void vhost_vq_reset(struct vhost_dev *dev, vq->avail_idx = 0; vq->last_used_idx = 0; vq->used_flags = 0; - vq->used_flags = 0; vq->log_used = false; vq->log_addr = -1ull; vq->vhost_hlen = 0; -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
> "Michael S. Tsirkin" > > On Tue, Oct 26, 2010 at 02:38:53PM +0530, Krishna Kumar2 wrote: > > Results for UDP BW tests (unidirectional, sum across > > 3 iterations, each iteration of 45 seconds, default > > netperf, vhosts bound to cpus 0-3; no other tuning): > > Is binding vhost threads to CPUs really required? > What happens if we let the scheduler do its job? Nothing drastic, I remember BW% and SD% both improved a bit as a result of binding. I started binding vhost thread after Avi suggested it in response to my v1 patch (he suggested some more that I haven't done), and have been doing only this tuning ever since. This is part of his mail for the tuning: >vhost: >thread #0: CPU0 >thread #1: CPU1 >thread #2: CPU2 >thread #3: CPU3 I simply bound each thread to CPU0-3 instead. Thanks, - KK -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
On Tue, Oct 26, 2010 at 02:38:53PM +0530, Krishna Kumar2 wrote: > Results for UDP BW tests (unidirectional, sum across > 3 iterations, each iteration of 45 seconds, default > netperf, vhosts bound to cpus 0-3; no other tuning): Is binding vhost threads to CPUs really required? What happens if we let the scheduler do its job? -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Page Eviction Algorithm
Hi All, I was just going over TODO list on KVM page. In MMU related TODO I saw only page eviction algorithm currently implemented is FIFO. Is it really the case? If yes I would like to work on it. Can someone let me know the place where the FIFO code is implemented? Thanks and Regards, Prasad -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
Krishna Kumar2/India/IBM wrote on 10/26/2010 10:40:35 AM: > > I am trying to wrap my head around kernel/user interface here. > > E.g., will we need another incompatible change when we add multiple RX > > queues? > > Though I added a 'mq' option to qemu, there shouldn't be > any incompatibility between old and new qemu's wrt vhost > and virtio-net drivers. So the old qemu will run new host > and new guest without issues, and new qemu can also run > old host and old guest. Multiple RXQ will also not add > any incompatibility. > > With MQ RX, I will be able to remove the hueristic (idea > from David Stevens). The idea is: Guest sends out packets > on, say TXQ#2, vhost#2 processes the packets but packets > going out from host to guest might be sent out on a > different RXQ, say RXQ#4. Guest receives the packet on > RXQ#4, and all future responses on that connection are sent > on TXQ#4. Now vhost#4 processes both RX and TX packets for > this connection. Without needing to hash on the connection, > guest can make sure that the same vhost thread will handle > a single connection. > > > Also need to think about how robust our single stream heuristic is, > > e.g. what are the chances it will misdetect a bidirectional > > UDP stream as a single TCP? > I think it should not happen. The hueristic code gets > called for handling just the transmit packets, packets > that vhost sends out to the guest skip this path. > > I tested unidirectional and bidirectional UDP to confirm: > > 8 iterations of iperf tests, each iteration of 15 secs, > result is the sum of all 8 iterations in Gbits/sec > __ > Uni-directional Bi-directional > Org New Org New > __ > 71.7871.77 71.74 72.07 > __ Results for UDP BW tests (unidirectional, sum across 3 iterations, each iteration of 45 seconds, default netperf, vhosts bound to cpus 0-3; no other tuning): -- numtxqs=8, vhosts=5 - # BW%CPU%SD% 1 .491.07 0 223.51 52.5126.66 475.17 72.438.57 886.54 80.2127.85 16 92.37 85.996.27 24 91.37 84.918.41 32 89.78 82.903.31 48 89.85 79.95 -3.57 64 85.83 80.282.22 80 88.90 79.47 -23.18 96 90.12 79.9814.71 128 86.13 80.604.42 BW: 71.3%, CPU: 80.4%, SD: 1.2% -- numtxqs=16, vhosts=5 #BW% CPU% SD% 11.80 00 219.8150.6826.66 457.3152.778.57 8108.44 88.19 -5.21 16 106.09 85.03 -4.44 24 102.34 84.23 -.82 32 102.77 82.71 -5.81 48 100.00 79.62 -7.29 64 96.8679.75 -6.10 80 99.2679.82 -27.34 96 94.7980.02 -5.08 128 98.1481.15 -15.25 BW: 77.9%, CPU: 80.4%, SD: -13.6% Thanks, - KK -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
On Mon, Oct 25, 2010 at 09:20:38PM +0530, Krishna Kumar2 wrote: > > Krishna Kumar2/India/i...@ibmin wrote on 10/20/2010 02:24:52 PM: > > Any feedback, comments, objections, issues or bugs about the > patches? Please let me know if something needs to be done. > > Some more test results: > _ > Host->Guest BW (numtxqs=2) > # BW% CPU%RCPU% SD% RSD% > _ I think we discussed the need for external to guest testing over 10G. For large messages we should not see any change but you should be able to get better numbers for small messages assuming a MQ NIC card. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: get rid of srcu idx
On Tue, Oct 26, 2010 at 10:06:41AM +0200, Avi Kivity wrote: > On 10/26/2010 10:01 AM, Gleb Natapov wrote: > >On Tue, Oct 26, 2010 at 09:57:08AM +0200, Avi Kivity wrote: > >> On 10/26/2010 08:58 AM, Gleb Natapov wrote: > >> >> > >> >> Well, you just changed where srcu index is saved. I don't see how it > >> >> could make a difference in practice. > >> >> > >> >If there is nested call to srcu read lock if srcu_idx is stored in vcpu > >> >nested call will override previous srcu_idx value and srcu unlock will > >> >not be called on it, but it will be called twice on new srcu_idx value. > >> >If srcu_idx is saved on stack this will not happen, no? > >> > >> Exactly. The case where srcu_idx is passed as a pointer parameter > >> is still dubious, but we can change that too. > >> > >But shouldn't we disallow recursive srcu lock tacking? > > With different srcu_idx, nested (or overlapping) srcu is legal. Right. If vcpu_enter_guest gets calles under a nested srcu call we'll still get a deadlock, however. > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Delivery Failure
- The message you sent to mptourism.com/aloksaxena was rejected because it would exceed the quota for the mailbox. The subject of the message follows: Subject: Returned mail: see transcript for details - -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for Oct 26
On 10/25/2010 09:51 PM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. 0.13.1 At least two fatal issues: - vmmouse is broken - assertion failure in block layer -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] Add a global synchronization point for pvclock
On 10/26/2010 01:30 AM, Jeremy Fitzhardinge wrote: Unfortunately this is breaking Xen save/restore: if you restore on a host which was booted more recently than the save host, causing the system time to be smaller. The effect is that the domain's time leaps forward to a fixed point, and stays there until the host catches up to the source host... Shouldn't save/restore also save the timebase? I guess last_time needs to be reset on this type of event. I guess the cleanest way would be for pvclock.c to register a sysdev suspend/resume handler. Should be for Xen only; kvm save/restore doesn't involve the guest. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: Avoid double interrupt injection with vapic
After an interrupt injection, the PPR changes, and we have to reflect that
into the vapic. This causes a KVM_REQ_EVENT to be set, which causes the
whole interrupt injection routine to be run again (harmlessly).
Optimize by only setting KVM_REQ_EVENT if the ppr was lowered; otherwise
there is no chance that a new injection is needed.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/lapic.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 413f897..93cf9d0 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -277,7 +277,8 @@ static void apic_update_ppr(struct kvm_lapic *apic)
if (old_ppr != ppr) {
apic_set_reg(apic, APIC_PROCPRI, ppr);
- kvm_make_request(KVM_REQ_EVENT, apic->vcpu);
+ if (ppr < old_ppr)
+ kvm_make_request(KVM_REQ_EVENT, apic->vcpu);
}
}
--
1.7.3.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: get rid of srcu idx
On 10/26/2010 10:01 AM, Gleb Natapov wrote: On Tue, Oct 26, 2010 at 09:57:08AM +0200, Avi Kivity wrote: > On 10/26/2010 08:58 AM, Gleb Natapov wrote: > >> > >> Well, you just changed where srcu index is saved. I don't see how it > >> could make a difference in practice. > >> > >If there is nested call to srcu read lock if srcu_idx is stored in vcpu > >nested call will override previous srcu_idx value and srcu unlock will > >not be called on it, but it will be called twice on new srcu_idx value. > >If srcu_idx is saved on stack this will not happen, no? > > Exactly. The case where srcu_idx is passed as a pointer parameter > is still dubious, but we can change that too. > But shouldn't we disallow recursive srcu lock tacking? With different srcu_idx, nested (or overlapping) srcu is legal. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks
On 10/25/2010 08:38 PM, Blue Swirl wrote:
>
> I don't really see why we need registration; cpu_register_io() takes
> function pointers, a size, and an opaque, and gives an integer handle in
> return. With the IOPort object approach, you set up the IOPort with
> function pointers, size is implied, and the opaque is derived using
> container_of(); the handle is simply the address of the object.
With the handle, we can separate setting up the structures at device
level, and mapping the object using only the handle at bus or other
higher level. Can this be done with the object approach?
I believe so. The handle is simply an indirect pointer, no?
The purpose of that patch series was to perform the separation for PCI
BARs. I wasn't so happy with the series, so I never pushed.
In fact I think an IOPort is even more suitable; if we need additional
attributes we can use a derived object:
struct PCIIOPort {
IOPort ioport;
/* additional fields */
};
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: get rid of srcu idx
On Tue, Oct 26, 2010 at 09:57:08AM +0200, Avi Kivity wrote: > On 10/26/2010 08:58 AM, Gleb Natapov wrote: > >> > >> Well, you just changed where srcu index is saved. I don't see how it > >> could make a difference in practice. > >> > >If there is nested call to srcu read lock if srcu_idx is stored in vcpu > >nested call will override previous srcu_idx value and srcu unlock will > >not be called on it, but it will be called twice on new srcu_idx value. > >If srcu_idx is saved on stack this will not happen, no? > > Exactly. The case where srcu_idx is passed as a pointer parameter > is still dubious, but we can change that too. > But shouldn't we disallow recursive srcu lock tacking? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: get rid of srcu idx
On 10/26/2010 08:58 AM, Gleb Natapov wrote: > > Well, you just changed where srcu index is saved. I don't see how it > could make a difference in practice. > If there is nested call to srcu read lock if srcu_idx is stored in vcpu nested call will override previous srcu_idx value and srcu unlock will not be called on it, but it will be called twice on new srcu_idx value. If srcu_idx is saved on stack this will not happen, no? Exactly. The case where srcu_idx is passed as a pointer parameter is still dubious, but we can change that too. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
