<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.emulators.kvm.devel">
    <title>gmane.comp.emulators.kvm.devel</title>
    <link>http://blog.gmane.org/gmane.comp.emulators.kvm.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91589"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91583"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91582"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91576"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91567"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91566"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91565"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91535"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91503"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91457"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91434"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91432"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91395"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91388"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91383"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91379"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91378"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91377"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91365"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91332"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91589">
    <title>FROM MRS SUSAN SHABANGU(OPEN THE ATTACH FILES)</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91589</link>
    <description>&lt;pre&gt;&lt;/pre&gt;</description>
    <dc:creator>FROM MRS SUSAN SHABANGU</dc:creator>
    <dc:date>2012-05-26T10:50:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91583">
    <title>UDP problem with virtio...</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91583</link>
    <description>&lt;pre&gt;Hi,


I am running a guest that exposes a NFS share to be used by a TViX box. The TViX box is not that advanced and uses NFS over UDP instead of TCP.
What I am seeing is that when I use the virtio network driver, the TViX box cannot mount the filesystem. However, when I use rtl8139 instead, it can.

The problem is easily reproduced:
1. Create a guest that uses a virtio network interface (bridging setup)
2. Expose an NFS share on the guest
3. mount the NFS share using 'mount -o udp host:/share /localdir'
4. verify that the NFS share cannot be mounted.
5. Modify the guest to use rtl8139 device emulation and stop the guest and start it
6. mount the NFS share using 'mount -o udp host:/share /localdir'
7. Verify tha the NFS share can be mounted

Now the bug reporting guidelines say that I should always use the latest KVM version but compiling KVM from source and using that is not really an option. The server is important enough not to mess around with. Therefore, my question is whether this problem has been seen &lt;/pre&gt;</description>
    <dc:creator>Erik Brakkee</dc:creator>
    <dc:date>2012-05-25T20:55:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91582">
    <title>[PATCH v2] KVM: Cleanup the kvm_print functions and introduce pr_XX wrappers</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91582</link>
    <description>&lt;pre&gt;Introduces a couple of print functions, which are essentially wrappers
around standard printk functions, with a KVM: prefix.

Functions introduced or modified are:
 - kvm_err(fmt, ...)
 - kvm_info(fmt, ...)
 - kvm_debug(fmt, ...)
 - kvm_pr_unimpl(fmt, ...)
 - pr_unimpl(vcpu, fmt, ...) -&amp;gt; vcpu_unimpl(vcpu, fmt, ...)

Applies to kvm-next

Changelog[2]:
 - Added PID to print functions
 - Renamed vcpu_pr_unimpl to vcpu_unimpl

 Signed-off-by: Christoffer Dall &amp;lt;c.dall&amp;lt; at &amp;gt;virtualopensystems.com&amp;gt;
---
 arch/x86/kvm/svm.c       |    6 +++--
 arch/x86/kvm/vmx.c       |    2 +-
 arch/x86/kvm/x86.c       |   54 +++++++++++++++++++++++-----------------------
 include/linux/kvm_host.h |   17 +++++++++-----
 4 files changed, 42 insertions(+), 37 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f75af40..7a41878 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3185,8 +3185,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int svm_set_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 data)
 break;
 case MSR_IA32_DEBUGCTLMSR:
 if (&lt;/pre&gt;</description>
    <dc:creator>Christoffer Dall</dc:creator>
    <dc:date>2012-05-25T16:22:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91576">
    <title>[PATCH v4] uq/master: Expose CPUID leaf 7 only for -cpu host</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91576</link>
    <description>&lt;pre&gt;Changes v3 -&amp;gt; v4:
  - Wrap line at cpu_x86_fill_host() to make checkpatch.pl happy

Changes v2 -&amp;gt; v3;
  - Check for kvm_enabled() before setting cpuid_7_0_ebx_features

Changes v1 -&amp;gt; v2:
  - Use kvm_arch_get_supported_cpuid() instead of host_cpuid() on
    cpu_x86_fill_host().

  We should use GET_SUPPORTED_CPUID for all bits on "-cpu host"
  eventually, but I am not changing all the other CPUID leaves because
  we may not be able to test such an intrusive change in time for 1.1.

Description of the bug:

Since QEMU 0.15, the CPUID information on CPUID[EAX=7,ECX=0] is being
returned unfiltered to the guest, directly from the GET_SUPPORTED_CPUID
return value.

The problem is that this makes the resulting CPU feature flags
unpredictable and dependent on the host CPU and kernel version. This
breaks live-migration badly if migrating from a host CPU that supports
some features on that CPUID leaf (running a recent kernel) to a kernel
or host CPU that doesn't support it.

Migration also is incorrect (the virtual CP&lt;/pre&gt;</description>
    <dc:creator>Eduardo Habkost</dc:creator>
    <dc:date>2012-05-25T14:55:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91567">
    <title>[PATCH v4 13/16] net: Make "info network" output more readable info</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91567</link>
    <description>&lt;pre&gt;From: Zhi Yong Wu &amp;lt;wuzhy&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;

Reviewed-by:   Jan Kiszka  &amp;lt;jan.kiszka&amp;lt; at &amp;gt;siemens.com&amp;gt;
Signed-off-by: Zhi Yong Wu &amp;lt;wuzhy&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
---
 net.c     |   18 ++++++++++++++----
 net.h     |    1 +
 net/hub.c |   23 +++++++++++++++++++++--
 net/hub.h |    1 +
 4 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/net.c b/net.c
index 61dc28d..ae0deec 100644
--- a/net.c
+++ b/net.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -887,6 +887,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static const struct {
         },
     },
 #endif /* CONFIG_NET_BRIDGE */
+    [NET_CLIENT_TYPE_HUB] = {
+        .type = "hubport",
+        .desc = {
+            { /* end of list */ }
+        },
+    },
 };
 
 int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1068,7 +1074,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
     return 0;
 }
 
-static void print_net_client(Monitor *mon, NetClientState *vc)
+void print_net_client(Monitor *mon, NetClientState *vc)
 {
     monitor_printf(mon, "%s: type=%s,%s\n", vc-&amp;gt;name,
                    ne&lt;/pre&gt;</description>
    <dc:creator>zwu.kernel&lt; at &gt;gmail.com</dc:creator>
    <dc:date>2012-05-25T14:11:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91566">
    <title>[PATCH v3] uq/master: Expose CPUID leaf 7 only for -cpu host</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91566</link>
    <description>&lt;pre&gt;[re-submitting to get this in through uq/master]

Changes v2 -&amp;gt; v3;
  - Check for kvm_enabled() before setting cpuid_7_0_ebx_features

Changes v1 -&amp;gt; v2:
  - Use kvm_arch_get_supported_cpuid() instead of host_cpuid() on
    cpu_x86_fill_host().

  We should use GET_SUPPORTED_CPUID for all bits on "-cpu host"
  eventually, but I am not changing all the other CPUID leaves because
  we may not be able to test such an intrusive change in time for 1.1.

Description of the bug:

Since QEMU 0.15, the CPUID information on CPUID[EAX=7,ECX=0] is being
returned unfiltered to the guest, directly from the GET_SUPPORTED_CPUID
return value.

The problem is that this makes the resulting CPU feature flags
unpredictable and dependent on the host CPU and kernel version. This
breaks live-migration badly if migrating from a host CPU that supports
some features on that CPUID leaf (running a recent kernel) to a kernel
or host CPU that doesn't support it.

Migration also is incorrect (the virtual CPU changes under the guest's
feet) &lt;/pre&gt;</description>
    <dc:creator>Eduardo Habkost</dc:creator>
    <dc:date>2012-05-25T14:12:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91565">
    <title>[PATCH v4 13/16] net: Make "info network" output more readable info</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91565</link>
    <description>&lt;pre&gt;From: Zhi Yong Wu &amp;lt;wuzhy&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;

Reviewed-by:   Jan Kiszka  &amp;lt;jan.kiszka&amp;lt; at &amp;gt;siemens.com&amp;gt;
Signed-off-by: Zhi Yong Wu &amp;lt;wuzhy&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
---
 net.c     |   18 ++++++++++++++----
 net.h     |   12 ++++++++++++
 net/hub.c |   23 +++++++++++++++++++++--
 net/hub.h |    1 +
 4 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/net.c b/net.c
index 61dc28d..ae0deec 100644
--- a/net.c
+++ b/net.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -887,6 +887,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static const struct {
         },
     },
 #endif /* CONFIG_NET_BRIDGE */
+    [NET_CLIENT_TYPE_HUB] = {
+        .type = "hubport",
+        .desc = {
+            { /* end of list */ }
+        },
+    },
 };
 
 int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1068,7 +1074,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
     return 0;
 }
 
-static void print_net_client(Monitor *mon, NetClientState *vc)
+void print_net_client(Monitor *mon, NetClientState *vc)
 {
     monitor_printf(mon, "%s: type=%s,%s\n", vc-&amp;gt;name,
           &lt;/pre&gt;</description>
    <dc:creator>zwu.kernel&lt; at &gt;gmail.com</dc:creator>
    <dc:date>2012-05-25T14:02:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91535">
    <title>[PATCH v4 16/16] hub: add the support for hub own flow control</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91535</link>
    <description>&lt;pre&gt;From: Zhi Yong Wu &amp;lt;wuzhy&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;

Only when all other hub port's *peer* .can_receive() all return 1, the source hub port .can_receive() return 1.

Signed-off-by: Zhi Yong Wu &amp;lt;wuzhy&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
---
 net/hub.c |   27 ++++++++++++++++++++++++---
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/net/hub.c b/net/hub.c
index 357ca87..478cce1 100644
--- a/net/hub.c
+++ b/net/hub.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -15,6 +15,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #include "monitor.h"
 #include "net.h"
 #include "hub.h"
+#include "iov.h"
 
 /*
  * A hub broadcasts incoming packets to all its ports except the source port.
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -59,16 +60,16 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort *source_port,
                                    const struct iovec *iov, int iovcnt)
 {
     NetHubPort *port;
-    ssize_t ret = 0;
+    ssize_t len = iov_size(iov, iovcnt);
 
     QLIST_FOREACH(port, &amp;amp;hub-&amp;gt;ports, next) {
         if (port == source_port) {
             continue;
         }
 
-        ret = qemu_sendv_packet(&amp;amp;port-&amp;gt;nc, iov, iovcnt)&lt;/pre&gt;</description>
    <dc:creator>zwu.kernel&lt; at &gt;gmail.com</dc:creator>
    <dc:date>2012-05-25T10:52:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91503">
    <title>[RFC PATCH] vfio: add fixup for broken PCI devices</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91503</link>
    <description>&lt;pre&gt;Some adapters (like NEC PCI USB controller) do not flush their config
on a sioftware reset and remember DMA config, etc.

If we use such an adapter with QEMU, then crash QEMU (stop it with
ctrl-A ctrl-X), and try to use it in QEMU again, it may start working
immediately with previous config when pci_enable_device() is called
on that PCI function.

To eliminate such effect, some quirk should be called. The proposed
pci_fixup_final does its job well for mentioned NEC PCI USB but not
sure if it is 100% correct.

Signed-off-by: Alexey Kardashevskiy &amp;lt;aik&amp;lt; at &amp;gt;ozlabs.ru&amp;gt;
---
 drivers/vfio/pci/vfio_pci.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 1e5315c..6e7c12d 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -88,6 +88,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void vfio_pci_disable(struct vfio_pci_device *vdev)
 {
 int bar;
 
+pci_fixup_device(pci_fixup_final, vdev-&amp;gt;pdev);
+
 pci_disable_device(vdev-&amp;gt;pdev);
 
 vfio_pci_se&lt;/pre&gt;</description>
    <dc:creator>Alexey Kardashevskiy</dc:creator>
    <dc:date>2012-05-25T07:35:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91457">
    <title>Date: 24/05/2012.</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91457</link>
    <description>&lt;pre&gt;Dear friend                                 24/05/2012.
I am Dr Raymond Chien Independent Non-executive Director of Hang Seng
Bank Hong Kong I have a business transaction of $44.5 million USD
to share with you,If interested contact me for more details via my
personal email:  draymndch8&amp;lt; at &amp;gt;yahoo.co.jp
Full names:Address:Age:Occupation:Phone/Fax
Regards: Date: 24/05/2012.
Dr Raymond Chien Kuo Fung 
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>From Hang Seng Bank</dc:creator>
    <dc:date>2012-05-24T20:47:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91434">
    <title>[PATCH v3 00/16] net: hub-based networking</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91434</link>
    <description>&lt;pre&gt;From: Zhi Yong Wu &amp;lt;wuzhy&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;

The patchset implements network hub stead of vlan. The main work was done by stefan, and i rebased it to latest QEMU upstream, did some testings and am responsible for pushing it to QEMU upstream.

Changelog from v2:
  1.) add the support for hub own flow control [paolo]
  2.) make the monitor output more reasonable hub info [jan kiszka]

v2:
  1.) cleanup some obsolete vlan info
  2.) cleanup deliver/deliver_iov func pointers [paolo]
  3.) support more flexible flow control [paolo]

Stefan Hajnoczi (12):
  net: Add a hub net client
  net: Use hubs for the vlan feature
  net: Look up 'vlan' net clients using hubs
  hub: Check that hubs are configured correctly
  net: Drop vlan argument to qemu_new_net_client()
  net: Remove vlan qdev property
  net: Remove vlan code from net.c
  net: Remove VLANState
  net: Rename non_vlan_clients to net_clients
  net: Rename VLANClientState to NetClientState
  net: Rename vc local variables to nc
  net: Rename qemu_del_vlan_clie&lt;/pre&gt;</description>
    <dc:creator>zwu.kernel&lt; at &gt;gmail.com</dc:creator>
    <dc:date>2012-05-24T17:59:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91432">
    <title>[PATCH 1/2] Remove kvm_commit_irq_routes from error messages</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91432</link>
    <description>&lt;pre&gt;Make my life a bit easier and report the correct function names.
s/kvm_commit_irq_routes/kvm_irqchip_commit_routes

Signed-off-by: Richard Weinberger &amp;lt;richard&amp;lt; at &amp;gt;nod.at&amp;gt;
---
 hw/device-assignment.c |    4 ++--
 hw/msi.c               |    2 +-
 hw/msix.c              |    4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 1daadb9..09726f9 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -958,7 +958,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void assigned_dev_update_msi(PCIDevice *pci_dev)
 
         kvm_add_routing_entry(kvm_state, assigned_dev-&amp;gt;entry);
         if (kvm_irqchip_commit_routes(kvm_state) &amp;lt; 0) {
-            perror("assigned_dev_update_msi: kvm_commit_irq_routes");
+            perror("assigned_dev_update_msi: kvm_irqchip_commit_routes");
             assigned_dev-&amp;gt;cap.state &amp;amp;= ~ASSIGNED_DEVICE_MSI_ENABLED;
             return;
         }
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1053,7 +1053,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
     }
 
     if&lt;/pre&gt;</description>
    <dc:creator>Richard Weinberger</dc:creator>
    <dc:date>2012-05-24T17:02:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91395">
    <title>which branch of kvm.git should I do regular testing against?</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91395</link>
    <description>&lt;pre&gt;Hi Avi,
Our team spare some effort in regular nightly testing against KVM upstream.
We're using master branch now and all the test reports I sent out are based on master branch.
Which branch of kvm.git should we do regular testing against?
Your suggestion?

I know next branch contains latest KVM patches. 
But I found some recent KVM patches in master branch never existed in next branch.
And, the next branch is based on linux3.4-rc3, while master branch is based on linux3.4-rc7.
Another question is whether the patches in next branch will be finally merged into master branch?


Best Regards,
     Yongjie (Jay)

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Ren, Yongjie</dc:creator>
    <dc:date>2012-05-24T09:24:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91388">
    <title>[RFC PATCH] PCI: Introduce INTx check &amp; mask API</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91388</link>
    <description>&lt;pre&gt;[Found while debugging VFIO on POWER but it is platform independent]

There is a feature in PCI (&amp;gt;=2.3?) to mask/unmask INTx via PCI_COMMAND and
PCI_STATUS registers.

And there is some API to support that (commit a2e27787f893621c5a6b865acf6b7766f8671328).

I have a network adapter:
0001:00:01.0 Ethernet controller: Chelsio Communications Inc T310 10GbE Single Port Adapter
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast &amp;gt;TAbort- &amp;lt;TAbort- &amp;lt;MAbort- &amp;gt;SERR- &amp;lt;PERR- INTx-

pci_intx_mask_supported() reports that the feature is supported for this adapter
BUT the adapter does not set PCI_STATUS_INTERRUPT so pci_check_and_set_intx_mask()
never changes PCI_COMMAND and INTx does not work on it when we use it as VFIO-PCI device.

If I remove the check of this bit, it works fine as it is called from an interrupt handler and
Status bit check is redundant.

Opened a spec:
PCI LOCAL BUS SPECIFICATION, REV. 3.0, Table&lt;/pre&gt;</description>
    <dc:creator>Alexey Kardashevskiy</dc:creator>
    <dc:date>2012-05-24T07:44:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91383">
    <title>[PATCH] vfio-powerpc: enabled and supported on power</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91383</link>
    <description>&lt;pre&gt;The patch introduces support of VFIO on POWER.

The patch consists of:

1. IOMMU driver for VFIO.
It does not use IOMMU API at all, instead it calls POWER
IOMMU API directly (ppc_md callbacks).

2. A piece of code (module_init) which creates IOMMU groups.
TBD: what is a better place for it?

The patch is made on top of
git://github.com/awilliam/linux-vfio.git iommu-group-vfio-20120523
(which is iommu-group-vfio-20120521 + some fixes)

Signed-off-by: Alexey Kardashevskiy &amp;lt;aik&amp;lt; at &amp;gt;ozlabs.ru&amp;gt;
---
 arch/powerpc/Kconfig             |    6 +
 arch/powerpc/include/asm/iommu.h |    3 +
 arch/powerpc/kernel/Makefile     |    1 +
 arch/powerpc/kernel/iommu_vfio.c |  371 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 381 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/kernel/iommu_vfio.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index feab3ba..13d12ac 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -319,6 +319,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; config 8XX_MINIMAL_FPEMU
 config IOMMU_HELPER
 def&lt;/pre&gt;</description>
    <dc:creator>Alexey Kardashevskiy</dc:creator>
    <dc:date>2012-05-24T03:10:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91379">
    <title>[PATCH 1/3 - qemu-kvm stable-1.0] Fix conditional build of various x86 specific bits</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91379</link>
    <description>&lt;pre&gt;This adds/modifies ifdefs etc. and moves code to make sure that
x86-specific code doesn't get compiled on non-x86 platforms.
These changes all relate to code that is in the qemu-kvm tree and
not in the qemu tree.

The change from KVM_CAP_IRQCHIP to KVM_IRQCHIP_PIC_MASTER is because
the KVM_CAP_IRQCHIP symbol is defined on all platforms (though the
capability only exists on x86), whereas KVM_IRQCHIP_PIC_MASTER is
only defined on x86.  (If a better symbol exists it could be used
instead.)

Signed-off-by: Benjamin Herrenschmidt &amp;lt;benh&amp;lt; at &amp;gt;kernel.crashing.org&amp;gt;
---

An equivalent of this is already in qemu-kvm master as commit id
20ad1def644494f5055d129961d46b050c0a6158

 Makefile.target |    2 ++
 configure       |    6 ++++--
 hw/i8259.c      |    6 ++++--
 qemu-kvm-x86.c  |   16 ++++++++++++++++
 qemu-kvm.c      |   30 ++++++++++++++----------------
 5 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 29eaa68..0d0baf4 100644
--- a/Makefile.target
+++ b/Makefile.t&lt;/pre&gt;</description>
    <dc:creator>Benjamin Herrenschmidt</dc:creator>
    <dc:date>2012-05-24T02:14:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91378">
    <title>[PATCH 3/3 - qemu-kvm stable-1.0] Fix kVM_GET_ONE_REG interface</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91378</link>
    <description>&lt;pre&gt;Qemu-1.0 included some code to use a new get/set one register interface
to KVM which unfortunately hadn't settled, and in the end the code that
went into the kernel provides a different interface.  This updates qemu
to use the new interface.

Since the 3.3 kernel doesn't provide this interface, in either the new
or the old form, this removes the check that caused qemu to bail out
if the ioctl returns an error.  In fact we don't even print a message,
since it got printed once per vcpu, which gets a bit tedious with more
than a few vcpus.

Signed-off-by: Benjamin Herrenschmidt &amp;lt;benh&amp;lt; at &amp;gt;kernel.crashing.org&amp;gt;
---

This is unnecessary in qemu-master and the main qemu as both have already
been updated with the correct interfaces.

 linux-headers/asm-powerpc/kvm.h |    2 +-
 linux-headers/linux/kvm.h       |   35 +++++++++++++++++++----------------
 target-ppc/kvm.c                |   12 ++++++++----
 3 files changed, 28 insertions(+), 21 deletions(-)

diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-po&lt;/pre&gt;</description>
    <dc:creator>Benjamin Herrenschmidt</dc:creator>
    <dc:date>2012-05-24T02:15:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91377">
    <title>[PATCH 2/3 - qemu-kvm stable-1.0] Allow i8259 to build without i8254</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91377</link>
    <description>&lt;pre&gt;This allows the i8259 emulation to be compiled without the i8254
emulation.

Currently the i8259 emulation code references some variables defined
in i8254.c for the "time-drift fix".  This moves the definitions from
i8254.c to i8259.c so that i8259.c becomes independent of i8254.c.

Signed-off-by: Benjamin Herrenschmidt &amp;lt;benh&amp;lt; at &amp;gt;kernel.crashing.org&amp;gt;
---

This appears to be unnecessary on qemu-kvm master or the main qemu

 hw/i8254.c |    3 ++-
 hw/i8259.c |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/i8254.c b/hw/i8254.c
index 019c7b8..878a47b 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -348,7 +348,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static uint32_t pit_ioport_read(void *opaque, uint32_t addr)
 }
 
 /* global counters for time-drift fix */
-int64_t timer_acks=0, timer_interrupts=0, timer_ints_to_push=0;
+extern int64_t timer_acks, timer_ints_to_push;
+int64_t timer_interrupts=0;
 
 extern int time_drift_fix;
 
diff --git a/hw/i8259.c b/hw/i8259.c
index c5841c0..f33a25d 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
&amp;lt; at &amp;gt;&lt;/pre&gt;</description>
    <dc:creator>Benjamin Herrenschmidt</dc:creator>
    <dc:date>2012-05-24T02:15:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91365">
    <title>[PATCH] kvm: document lapic regs field</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91365</link>
    <description>&lt;pre&gt;The logic in find_highest_vector looks
strange until you realize the reason for the
weird memory layout, which is because this is
what the CPU microcode expects.

Add a comment so this stops tripping people up.

Signed-off-by: Michael S. Tsirkin &amp;lt;mst&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 arch/x86/kvm/lapic.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 41c62c7..1d1ec08 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -15,6 +15,11 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct kvm_lapic {
 bool irr_pending;
 s16 isr_count;
 int isr_cache;
+/**
+ * APIC register page.  The layout matches the register layout seen by
+ * the guest 1:1, because it is accessed by the vmx microcode.
+ * Note: Only one register, the TPR, is used by the microcode.
+ */
 void *regs;
 gpa_t vapic_addr;
 struct page *vapic_page;
&lt;/pre&gt;</description>
    <dc:creator>Michael S. Tsirkin</dc:creator>
    <dc:date>2012-05-23T16:16:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91332">
    <title>[PATCH 0/2] improve speed of "rep ins" emulation</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91332</link>
    <description>&lt;pre&gt;With this patches loading 100M initrd takes ~10s instead of ~40s without.

Gleb Natapov (2):
  Provide userspace IO exit completion callback.
  Provide fast path for "rep ins" emulation if possible.

 arch/x86/include/asm/kvm_host.h |    6 ++
 arch/x86/kvm/svm.c              |   20 +++-
 arch/x86/kvm/vmx.c              |   25 ++++--
 arch/x86/kvm/x86.c              |  187 +++++++++++++++++++++++++++++++--------
 4 files changed, 189 insertions(+), 49 deletions(-)

&lt;/pre&gt;</description>
    <dc:creator>Gleb Natapov</dc:creator>
    <dc:date>2012-05-23T14:08:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91329">
    <title>Is kvm-guest-drivers-linux.git still live? Is virtio-serial included?</title>
    <link>http://comments.gmane.org/gmane.comp.emulators.kvm.devel/91329</link>
    <description>&lt;pre&gt;Hi,
To support linux guests with old kernel version, vitio driver backport
is needed. But I cannot find kvm-guest-drivers-linux.git now.
From linux distributions' virtio backport versions, such as
virtio-0.1-18.el3.src.rpm for RHEl3 hat and
novell-virtio-drivers-2.6.27-sle10sp3.iso for SLES 10 sp3, virtio-serial
driver is not included.
Any advice is welcome.
Thanks in advance.

Regards,
Hongyong

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Zang Hongyong</dc:creator>
    <dc:date>2012-05-23T12:03:55</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.emulators.kvm.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.emulators.kvm.devel</link>
  </textinput>
</rdf:RDF>

