[PATCHv3 0/2] mm: use_mm/unuse_mm
This moves use_mm/unuse_mm from aio into mm, and optimizes atomic usage there. Original patchset also exported use_mm/unuse_mm to modules, for use by vhost, that bit will come in later when vhost is posted for inclusion. Michael S. Tsirkin (2): mm: move use_mm/unuse_mm from aio.c to mm/ mm: reduce atomic use on use_mm fast path fs/aio.c| 47 +-- include/linux/mmu_context.h |9 ++ mm/Makefile |2 +- mm/mmu_context.c| 58 +++ 4 files changed, 69 insertions(+), 47 deletions(-) create mode 100644 include/linux/mmu_context.h create mode 100644 mm/mmu_context.c -- 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
[PATCHv3 1/2] mm: move use_mm/unuse_mm from aio.c to mm/
Anyone who wants to do copy to/from user from a kernel thread, needs
use_mm (like what fs/aio has). Move that into mm/, to make reusing and
exporting easier down the line, and make aio use it. Next intended
user, besides aio, will be vhost-net.
Acked-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
fs/aio.c| 47 +
include/linux/mmu_context.h |9 +++
mm/Makefile |2 +-
mm/mmu_context.c| 55 +++
4 files changed, 66 insertions(+), 47 deletions(-)
create mode 100644 include/linux/mmu_context.h
create mode 100644 mm/mmu_context.c
diff --git a/fs/aio.c b/fs/aio.c
index d065b2c..fc21c23 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -24,6 +24,7 @@
#include linux/file.h
#include linux/mm.h
#include linux/mman.h
+#include linux/mmu_context.h
#include linux/slab.h
#include linux/timer.h
#include linux/aio.h
@@ -34,7 +35,6 @@
#include asm/kmap_types.h
#include asm/uaccess.h
-#include asm/mmu_context.h
#if DEBUG 1
#define dprintkprintk
@@ -595,51 +595,6 @@ static struct kioctx *lookup_ioctx(unsigned long ctx_id)
}
/*
- * use_mm
- * Makes the calling kernel thread take on the specified
- * mm context.
- * Called by the retry thread execute retries within the
- * iocb issuer's mm context, so that copy_from/to_user
- * operations work seamlessly for aio.
- * (Note: this routine is intended to be called only
- * from a kernel thread context)
- */
-static void use_mm(struct mm_struct *mm)
-{
- struct mm_struct *active_mm;
- struct task_struct *tsk = current;
-
- task_lock(tsk);
- active_mm = tsk-active_mm;
- atomic_inc(mm-mm_count);
- tsk-mm = mm;
- tsk-active_mm = mm;
- switch_mm(active_mm, mm, tsk);
- task_unlock(tsk);
-
- mmdrop(active_mm);
-}
-
-/*
- * unuse_mm
- * Reverses the effect of use_mm, i.e. releases the
- * specified mm context which was earlier taken on
- * by the calling kernel thread
- * (Note: this routine is intended to be called only
- * from a kernel thread context)
- */
-static void unuse_mm(struct mm_struct *mm)
-{
- struct task_struct *tsk = current;
-
- task_lock(tsk);
- tsk-mm = NULL;
- /* active_mm is still 'mm' */
- enter_lazy_tlb(mm, tsk);
- task_unlock(tsk);
-}
-
-/*
* Queue up a kiocb to be retried. Assumes that the kiocb
* has already been marked as kicked, and places it on
* the retry run list for the corresponding ioctx, if it
diff --git a/include/linux/mmu_context.h b/include/linux/mmu_context.h
new file mode 100644
index 000..70fffeb
--- /dev/null
+++ b/include/linux/mmu_context.h
@@ -0,0 +1,9 @@
+#ifndef _LINUX_MMU_CONTEXT_H
+#define _LINUX_MMU_CONTEXT_H
+
+struct mm_struct;
+
+void use_mm(struct mm_struct *mm);
+void unuse_mm(struct mm_struct *mm);
+
+#endif
diff --git a/mm/Makefile b/mm/Makefile
index 5e0bd64..46c3892 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -11,7 +11,7 @@ obj-y := bootmem.o filemap.o mempool.o
oom_kill.o fadvise.o \
maccess.o page_alloc.o page-writeback.o pdflush.o \
readahead.o swap.o truncate.o vmscan.o shmem.o \
prio_tree.o util.o mmzone.o vmstat.o backing-dev.o \
- page_isolation.o mm_init.o $(mmu-y)
+ page_isolation.o mm_init.o mmu_context.o $(mmu-y)
obj-y += init-mm.o
obj-$(CONFIG_PROC_PAGE_MONITOR) += pagewalk.o
diff --git a/mm/mmu_context.c b/mm/mmu_context.c
new file mode 100644
index 000..fd473b5
--- /dev/null
+++ b/mm/mmu_context.c
@@ -0,0 +1,55 @@
+/* Copyright (C) 2009 Red Hat, Inc.
+ *
+ * See ../COPYING for licensing terms.
+ */
+
+#include linux/mm.h
+#include linux/mmu_context.h
+#include linux/sched.h
+
+#include asm/mmu_context.h
+
+/*
+ * use_mm
+ * Makes the calling kernel thread take on the specified
+ * mm context.
+ * Called by the retry thread execute retries within the
+ * iocb issuer's mm context, so that copy_from/to_user
+ * operations work seamlessly for aio.
+ * (Note: this routine is intended to be called only
+ * from a kernel thread context)
+ */
+void use_mm(struct mm_struct *mm)
+{
+ struct mm_struct *active_mm;
+ struct task_struct *tsk = current;
+
+ task_lock(tsk);
+ active_mm = tsk-active_mm;
+ atomic_inc(mm-mm_count);
+ tsk-mm = mm;
+ tsk-active_mm = mm;
+ switch_mm(active_mm, mm, tsk);
+ task_unlock(tsk);
+
+ mmdrop(active_mm);
+}
+
+/*
+ * unuse_mm
+ * Reverses the effect of use_mm, i.e. releases the
+ * specified mm context which was earlier taken on
+ * by the calling kernel thread
+ * (Note: this routine is intended to be called only
+ * from a kernel thread context)
+ */
+void
[PATCHv3 2/2] mm: reduce atomic use on use_mm fast path
When mm switched to matches that of active mm, we don't need to
increment and then drop the mm count. In a simple benchmark this
happens in about 50% of time. Making that conditional reduces
contention on that cache line on SMP systems.
Acked-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
mm/mmu_context.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/mm/mmu_context.c b/mm/mmu_context.c
index fd473b5..ded9081 100644
--- a/mm/mmu_context.c
+++ b/mm/mmu_context.c
@@ -26,13 +26,16 @@ void use_mm(struct mm_struct *mm)
task_lock(tsk);
active_mm = tsk-active_mm;
- atomic_inc(mm-mm_count);
+ if (active_mm != mm) {
+ atomic_inc(mm-mm_count);
+ tsk-active_mm = mm;
+ }
tsk-mm = mm;
- tsk-active_mm = mm;
switch_mm(active_mm, mm, tsk);
task_unlock(tsk);
- mmdrop(active_mm);
+ if (active_mm != mm)
+ mmdrop(active_mm);
}
/*
--
1.6.2.5
--
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
Bridges problem with kvm
Hi all,
I have a strange problem with my bridges configuration. I have a
rhel5.4 host with kvm-83-105 package installed. This host has two
bridged interfaces defined to use with kvm guests:
DEVICE=prodif
ONBOOT=yes
TYPE=Bridge
IPADDR=172.26.50.14
NETMASK=255.255.255.240
DELAY=0
STP=off
and
DEVICE=iscsif
ONBOOT=yes
TYPE=Bridge
DELAY=0
STP=off
I have installed two kvm guests (rhel5.4 also) with two virtual
interfaces using virtio driver on one guest and e1000 driver on the
other guest.
My problem is: when I do a ping between these guests over prodif
bridge all works as expected: ping responds. But if I do another ping
over iscsif bridge doesn't works. The only difference between prodif
bridge and iscsif bridge is that prodif has an IP address.
More info:
a) brctl show on host:
bridge name bridge id STP enabled interfaces
iscsif 8000.c201b3289830 no vnet3
vnet1
prodif 8000.226af089f4c3 no vnet2
vnet0
b) sysctl.conf on host:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
I don't have iptables rules defined and net.ipv4.ip_forward is
disabled (but if I put sysctl -w net.ipv4.ip_forward=1, result is the same).
What am I doing wrong??
Many thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
--
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: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
On 09/17/2009 06:11 AM, Gregory Haskins wrote: irqfd/eventfd is the abstraction layer, it doesn't need to be reabstracted. Not per se, but it needs to be interfaced. How do I register that eventfd with the fastpath in Ira's rig? How do I signal the eventfd (x86-ppc, and ppc-x86)? You write a userspace or kernel module to do it. It's a few dozen lines of code. To take it to the next level, how do I organize that mechanism so that it works for more than one IO-stream (e.g. address the various queues within ethernet or a different device like the console)? KVM has IOEVENTFD and IRQFD managed with MSI and PIO. This new rig does not have the luxury of an established IO paradigm. Is vbus the only way to implement a solution? No. But it is _a_ way, and its one that was specifically designed to solve this very problem (as well as others). virtio assumes that the number of transports will be limited and interesting growth is in the number of device classes and drivers. So we have support for just three transports, but 6 device classes (9p, rng, balloon, console, blk, net) and 8 drivers (the preceding 6 for linux, plus blk/net for Windows). It would have nice to be able to write a new binding in Visual Basic but it's hardly a killer feature. Since vbus was designed to do exactly that, this is what I would advocate. You could also reinvent these concepts and put your own mux and mapping code in place, in addition to all the other stuff that vbus does. But I am not clear why anyone would want to. Maybe they like their backward compatibility and Windows support. This is really not relevant to this thread, since we are talking about Ira's hardware. But if you must bring this up, then I will reiterate that you just design the connector to interface with QEMU+PCI and you have that too if that was important to you. Well, for Ira the major issue is probably inclusion in the upstream kernel. But on that topic: Since you could consider KVM a motherboard manufacturer of sorts (it just happens to be virtual hardware), I don't know why KVM seems to consider itself the only motherboard manufacturer in the world that has to make everything look legacy. If a company like ASUS wants to add some cutting edge IO controller/bus, they simply do it. No, they don't. New buses are added through industry consortiums these days. No one adds a bus that is only available with their machine, not even Apple. Pretty much every product release may contain a different array of devices, many of which are not backwards compatible with any prior silicon. The guy/gal installing Windows on that system may see a ? in device-manager until they load a driver that supports the new chip, and subsequently it works. It is certainly not a requirement to make said chip somehow work with existing drivers/facilities on bare metal, per se. Why should virtual systems be different? Devices/drivers are a different matter, and if you have a virtio-net device you'll get the same ? until you load the driver. That's how people and the OS vendors expect things to work. What I was getting at is that you can't just hand-wave the datapath stuff. We do fast path in KVM with IRQFD/IOEVENTFD+PIO, and we do device discovery/addressing with PCI. That's not datapath stuff. Neither of those are available here in Ira's case yet the general concepts are needed. Therefore, we have to come up with something else. Ira has to implement virtio's -kick() function and come up with something for discovery. It's a lot less lines of code than there are messages in this thread. Yes. I'm all for reusing virtio, but I'm not going switch to vbus or support both for this esoteric use case. With all due respect, no one asked you to. This sub-thread was originally about using vhost in Ira's rig. When problems surfaced in that proposed model, I highlighted that I had already addressed that problem in vbus, and here we are. Ah, okay. I have no interest in Ira choosing either virtio or vbus. vhost-net somehow manages to work without the config stuff in the kernel. I was referring to data-path stuff, like signal and memory configuration/routing. signal and memory configuration/routing are not data-path stuff. Well, virtio has a similar abstraction on the guest side. The host side abstraction is limited to signalling since all configuration is in userspace. vhost-net ought to work for lguest and s390 without change. But IIUC that is primarily because the revectoring work is already in QEMU for virtio-u and it rides on that, right? Not knocking that, thats nice and a distinct advantage. It should just be noted that its based on sunk-cost, and not truly free. Its just already paid for, which is different. It also means it only works in environments based on QEMU, which not all are (as evident by this sub-thread). No. We expose a mix of
Re: SOLVED kvm networking on debian unstable
The solution is, to delete /etc/udev/rules.d/70-persistent-net.rules in the guest and reboot. This is an autogenerated file, which stores the mapping of MAC adresses to interface names. Since my MAC address changed, the interface wasn't automatically added anymore. found at: http://vmfaq.com/entry/24/ Thomas Koch, http://www.koch.ro -- 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-Bugs-2860533 ] guest: CTRL key unusable after host caps lock/ctrl swap
Bugs item #2860533, was opened at 2009-09-17 08:10
Message generated for change (Tracker Item Submitted) made by fkater2
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2860533group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Felix Kater (fkater2)
Assigned to: Nobody/Anonymous (nobody)
Summary: guest: CTRL key unusable after host caps lock/ctrl swap
Initial Comment:
* cpu: intel core 2 duo 2,4 ghz
* kvm version: kvm-88-r1 with -HAVE_KERNEL option (gentoo linux)
* vanilla-2.6.30.6
* x86_64
* guest: windows 2000, sp4
* start cmd: kvm \
-cpu core2duo \
-hda /vdiskw2k.img \
-m 800 \
-net nic,macaddr=${mac},vlan=0 \
-net tap,ifname=tap0,vlan=0,script=no
Summary: When you swap the keyboard keys CAPS LOCK and CTRL by thequite common
X configuration (in xorg.conf) then the CTRL key on the guest gets unusable and
other strange effects happen (see below).
To reproduce:
1) Swap keys by this setting in /etc/X11/xorg.conf:
Section InputDevice
Option XkbOptions ctrl:swapcaps
EndSection
2) Start kvm guest and optimally open a windows cmd console
3) Try switching between the guest and the host by keyboard using the key
sequence using ALT+CTRL (which is actually ALT+CAPS LOCK now).
4) Enter something in the guests console
Results:
1) most annoying: CTRL+something on the guest is not usable at all anymore
2) Letters are now always CAPITALS (like when caps lock pressed on the guest);
You can undo this only by switching back to the host and again to the guest or
by switch with the mouse click into the guest window; however the CTRL remains
unusable.
3) Caps Lock on the guest does not work either (or leads to even more confusion)
What I have tried:
1) Swapping CTRL + CAPS LOCK on the windows guest as well (by registry hack)
does NOT help
2) earlier kvm versions (same behaviour)
3) different X versions (server 1.5, 1.6)
4) swapping CTRL/CAPS LOCK now only in X but also by the linux console keymaps
Thank You!
Felix
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2860533group_id=180599
--
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 networking (NAT) on debian unstable with libvirt
Already sent to libvirt without response. Hi, I'm trying to get NAT networking running as described in http://libvirt.org/formatnetwork.html#examplesNAT But in the guest, ifconfig shows only the lo interface. I created the kvm image (debian lenny 5.0.3) directly with qemu-img and kvm, because virt- install also didn't work. Afterwards I created the XML file for libvirt: domain type='kvm' namehadoop1/name uuidc40b6644-362a-e5ab-8825-cd1a7fbe24eb/uuid memory524288/memory currentMemory524288/currentMemory vcpu1/vcpu os type arch='x86_64' machine='pc'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/bin/kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2'/ source file='/var/lib/libvirt/images/hadoop1.qcow2'/ target dev='hda' bus='ide'/ /disk interface type='network' mac address='52:54:00:05:74:bb'/ source network='default'/ model type='virtio'/ /interface !--serial type='pty' target port='0'/ /serial console type='pty' target port='0'/ /console-- input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes' keymap='de-ch'/ video model type='cirrus' vram='9216' heads='1'/ /video /devices /domain The network config is: network namedefault/name bridge name=virbr0 / forward/ ip address=192.168.122.1 netmask=255.255.255.0 dhcp range start=192.168.122.2 end=192.168.122.254 / /dhcp /ip /network ifconfig of the host (needs cleanup, I know): eth1 Link encap:Ethernet Hardware Adresse 00:1c:25:18:4d:e6 UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Speicher:fe20-fe22 eth1:avahi Link encap:Ethernet Hardware Adresse 00:1c:25:18:4d:e6 inet Adresse:169.254.6.97 Bcast:169.254.255.255 Maske:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 Speicher:fe20-fe22 loLink encap:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:16436 Metrik:1 RX packets:160751 errors:0 dropped:0 overruns:0 frame:0 TX packets:160751 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:27262569 (25.9 MiB) TX bytes:27262569 (25.9 MiB) virbr0Link encap:Ethernet Hardware Adresse 4a:30:15:4d:b5:0d inet Adresse:192.168.122.1 Bcast:192.168.122.255 Maske:255.255.255.0 inet6-Adresse: fe80::8804:ecff:febc:fa54/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:299 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:0 (0.0 B) TX bytes:47842 (46.7 KiB) vnet0 Link encap:Ethernet Hardware Adresse 4a:30:15:4d:b5:0d inet6-Adresse: fe80::4830:15ff:fe4d:b50d/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:128 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:500 RX bytes:0 (0.0 B) TX bytes:16426 (16.0 KiB) wlan0 Link encap:Ethernet Hardware Adresse 00:1d:e0:08:89:21 inet Adresse:192.168.178.23 Bcast:192.168.178.255 Maske:255.255.255.0 inet6-Adresse: fe80::21d:e0ff:fe08:8921/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:10608 errors:0 dropped:0 overruns:0 frame:0 TX packets:10358 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 RX bytes:7515487 (7.1 MiB) TX bytes:1367200 (1.3 MiB) wmaster0 Link encap:UNSPEC Hardware Adresse 00-1D- E0-08-89-21-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) The call to KVM from the libvirt log is (linebreaks by me): LC_ALL=C
Re: GDB + KVM Debug
Saksena, Abhishek wrote: I am using KVM-88. However I can't get gdb still working. I stared qemu with -s -S option and when I try to connect gdb to it I get following error:- (gdb) target remote lochost:1234 lochost: unknown host lochost:1234: No such file or directory. (gdb) target remote locahost:1234 locahost: unknown host locahost:1234: No such file or directory. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 [New Thread 1] Remote 'g' packet reply is too long: 2306f0ff023002f07f03000 0 (gdb) Try 'set arch target-architecture' before connecting. This is required if you didn't load the corresponding target image into gdb. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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
eepro100.c
Hi, I have question on i82557b emulation in kvm. I have run a proprietary operating system (Pharlap OS) in kvm. Part of the job has been porting driver for i8255x. During the job I discovered that kvm's emulation doesn't support a RNR interrupt (it is disabled in the code). Why is it disabled? I'm running heavily loaded application and I have to poll descriptor list instead of waiting for RNR interrupt. Thanks for answer Michal Filka -- 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: vhost-net todo list
On Wednesday 16 September 2009, Michael S. Tsirkin wrote: Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) So far, I could not find any theoretical solution how to fix this, but if you think it can be done, it would be good to have it on the list somewhere. Arnd -- 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: vhost-net todo list
On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) So far, I could not find any theoretical solution how to fix this, What if socket had a LOCKBIND ioctl after which you can not bind it to any other device? Then someone with RAW capability can open the socket, bind to device and hand it to you. You can send packets but not switch to another device. but if you think it can be done, it would be good to have it on the list somewhere. Arnd -- 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: Bridges problem with kvm (SOLVED)
carlopmart wrote:
Hi all,
I have a strange problem with my bridges configuration. I have a
rhel5.4 host with kvm-83-105 package installed. This host has two
bridged interfaces defined to use with kvm guests:
DEVICE=prodif
ONBOOT=yes
TYPE=Bridge
IPADDR=172.26.50.14
NETMASK=255.255.255.240
DELAY=0
STP=off
and
DEVICE=iscsif
ONBOOT=yes
TYPE=Bridge
DELAY=0
STP=off
I have installed two kvm guests (rhel5.4 also) with two virtual
interfaces using virtio driver on one guest and e1000 driver on the
other guest.
My problem is: when I do a ping between these guests over prodif bridge
all works as expected: ping responds. But if I do another ping over
iscsif bridge doesn't works. The only difference between prodif bridge
and iscsif bridge is that prodif has an IP address.
More info:
a) brctl show on host:
bridge name bridge id STP enabled interfaces
iscsif 8000.c201b3289830 no vnet3
vnet1
prodif 8000.226af089f4c3 no vnet2
vnet0
b) sysctl.conf on host:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
I don't have iptables rules defined and net.ipv4.ip_forward is disabled
(but if I put sysctl -w net.ipv4.ip_forward=1, result is the same).
What am I doing wrong??
Many thanks.
I find the problem: mac address used on kvm guests. I have chegend to
00:XX:XX:XX:XX:XX.
--
CL Martinez
carlopmart {at} gmail {d0t} com
--
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: vhost-net todo list
On Thursday 17 September 2009, Michael S. Tsirkin wrote: On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) So far, I could not find any theoretical solution how to fix this, What if socket had a LOCKBIND ioctl after which you can not bind it to any other device? Then someone with RAW capability can open the socket, bind to device and hand it to you. You can send packets but not switch to another device. Could work, though I was hoping for a solution that does not depend on a priviledged task at run time to open the socket, as you have with persistant tap devices or chardevs like macvtap that can have their persissions set by udev. Arnd -- 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: vhost-net todo list
On Thu, Sep 17, 2009 at 02:14:06PM +0200, Arnd Bergmann wrote: On Thursday 17 September 2009, Michael S. Tsirkin wrote: On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) So far, I could not find any theoretical solution how to fix this, What if socket had a LOCKBIND ioctl after which you can not bind it to any other device? Then someone with RAW capability can open the socket, bind to device and hand it to you. You can send packets but not switch to another device. Could work, though I was hoping for a solution that does not depend on a priviledged task at run time to open the socket, as you have with persistant tap devices or chardevs like macvtap that can have their persissions set by udev. Arnd Well, we could have a char device with an ioctl that gives you back a socket, or maybe even have it give you back a socket when you open it. Will that make you happy? -- 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: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
On Wed, Sep 16, 2009 at 10:11 PM, Gregory Haskins gregory.hask...@gmail.com wrote: It is certainly not a requirement to make said chip somehow work with existing drivers/facilities on bare metal, per se. Why should virtual systems be different? i'd guess it's an issue of support resources. a hardware developer creates a chip and immediately sells it, getting small but assured revenue, with it they write (or pays to write) drivers for a couple of releases, and stop to manufacture it as soon as it's not profitable. software has a much longer lifetime, especially at the platform-level (and KVM is a platform for a lot of us). also, being GPL, it's cheaper to produce but has (much!) more limited resources. creating a new support issue is a scary thought. -- Javier -- 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: vhost-net todo list
On Thursday 17 September 2009, Michael S. Tsirkin wrote: Well, we could have a char device with an ioctl that gives you back a socket, or maybe even have it give you back a socket when you open it. Will that make you happy? Well, that would put is in the exact same spot as the tun/tap driver patch you're working on or my (still unfinished, I need to spend some time on it again) macvtap driver. As I said, either one addresses the problem but is unrelated to the raw socket interface. Arnd -- 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
Greeting from patricia
Hello my dear, My name Patricia bouba i saw your email in my mail box i deceived to contact you so that i will know you the more and for you to know too please i want you to write me back in my mail box so that i will give you my picture for you know whom i am and i know too please don't say no to me contact me on this email (patricia4love...@yahoo.com) am waiting for your writing back me miss Patricia -- 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 0/7] KVM test: support for the new remote shell server for Windows
- Michael Goldish mgold...@redhat.com wrote: - Yolkfull Chow yz...@redhat.com wrote: On Tue, Aug 18, 2009 at 06:30:14PM -0400, Michael Goldish wrote: - Lucas Meneghel Rodrigues l...@redhat.com wrote: On Tue, Aug 18, 2009 at 7:15 AM, Michael Goldishmgold...@redhat.com wrote: - Lucas Meneghel Rodrigues l...@redhat.com wrote: Ok, very good, similarly to the previous patchset, I rebased one of the patches and applied the set, I am making tests with an rss binary generated by the cross compiler. I am testing with Winxp 32 bit, so far so good and rss.exe works as expected. I guess I will test more with other hosts, but I am not too far from applying this patchset as well. Will keep you posted! Hi Michael, so far rss works wonderful on remote login a VM and execute some simple commands. But can we expect extend the facility to enable it support some telnet commands, like 'wmic' ? We did need such commands which is used for collecting guest hardware information. I wasn't aware of wmic, but now that I tried running it, it appears to be one of those programs, like netsh and ftp, that behave badly when run outside an actual console window. In the case of netsh and ftp there are easy workarounds but wmic seems to hang no matter what I do. AFAIK, it doesn't work with SSH servers either, including openSSH under cygwin. I wonder how it works under telnet but it'll be difficult to find out because I don't have the MS telnet source code. I'll start looking for a solution/workaround. I think I've found a solution and I'm testing it now. If everything works as expected I'll send a patch soon. Note that this patchset should also allow you to install rss.exe automatically using step files, so I hope that in your tests you're not installing it manually. I'm not expecting you to test everything (it takes quite a while), but if you're testing anyway, better let the step files do some work too. (I know we'll start using unattended installation scripts soon but it doesn't hurt to have functional step files too.) Also note that using a certain qemu/KVM version I couldn't get Vista to work with user mode. This isn't an rss.exe problem. In TAP mode it works just fine. In any case, thanks for reviewing and testing the patchsets. Ok Michael, turns out the win2000 failure was a silly mistake. So, after checking the code and going trough light testing, I applied this patchset http://autotest.kernel.org/changeset/3553 http://autotest.kernel.org/changeset/3554 http://autotest.kernel.org/changeset/3555 http://autotest.kernel.org/changeset/3556 Maybe I'm misinterpreting this, but it looks like you squashed two patches together. The commit titled step file tests: do not fail when receiving an invalid screendump (changeset 3556) also makes changes to kvm_tests.cfg.sample (it's not supposed to), and the patch that's supposed to do it seems to be missing. This is probably not important -- I just thought I should bring it to your attention. Sudhir, perhaps you can try the upstream tree starting with r3556. It has all the changes you have asked for earlier (rss and stuff). In order to get things all set, I suggest: 1) Create a directory with the following contents: [...@freedom rss]$ ls -l total 52 -rwxrwxr-x. 1 lmr lmr 42038 2009-08-17 18:55 rss.exe -rw-rw-r--. 1 lmr lmr 517 2009-08-17 18:57 rss.reg -rw-rw-r--. 1 lmr lmr 972 2009-08-17 18:57 setuprss.bat Those can be found under client/tests/kvm/deps directory on the most current autotest tree. 2) Create an iso from it: genisoimage -o rss.iso -max-iso9660-filenames -relaxed-filenames -D --input-charset iso8859-1 rss 3) Put rss.iso under your windows iso directory. 4) Profit :) If you want to compile the latest rss, you could try numerous things, here are some possible routes: 1) Compile it under a windows host with mingw installed 2) Compile it under Fedora 12 with the cross compile environment installed, you need to install at least these through yum: mingw32-w32api mingw32-gcc-c++ mingw32-gcc And then do a: i686-pc-mingw32-g++ rss.cpp -lws2_32 -mwindows -o rss.exe I hope that was helpful. After this patch-applying spree, I gotta a *lot* of documentation to write to our wiki :) Cheers, Lucas -- 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:
Re: [ANNOUNCE] Release to community: Windows kvm/virtio guest drivers
Hi, There are any news about the new pv drivers? They would be very welcome by the community :) Cheers Armindo On Mon, Aug 17, 2009 at 4:03 PM, Yan Vugenfirer yvuge...@redhat.com wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Chris Howells Sent: Monday, August 17, 2009 5:18 PM To: kvm@vger.kernel.org Subject: Re: [ANNOUNCE] Release to community: Windows kvm/virtio guest drivers Hi, On Mon, August 17, 2009 2:21 pm, Yan Vugenfirer wrote: I am happy to announce the release of the Windows kvm/virtio guest drivers to open source community under GPLv2 license! Wiki: http://www.linux-kvm.org/page/WindowsGuestDrivers Thanks for these, they look very interesting. Unfortunately the download links appear to be broken. I followed the download link at http://www.linux-kvm.org/page/WindowsGuestDrivers/Last_WHQLed_drivers but when I click media:viostor.tar it prompts me to upload a file. Thanks [YV] Soon I will post the MS signed binaries. -- 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 -- -- The only way of discovering the limits of the possible is to venture a little way past them into the impossible. Sir Arthur C. Clarke -- 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
option -daemonize broken in -next branch of qemu-kvm
Hello, When using -daemonize the VM won't start and the following is printed: kvm_create_vcpu: Input/output error create_userspace_phys_mem: Input/output error kvm_cpu_register_physical_memory: failed Regards, Will Trives This email was sent from Netspace Webmail: http://www.netspace.net.au -- 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] gdbstub: x86: Switch 64/32 bit registers dynamically
Commit 56aebc891674cd2d07b3f64183415697be200084 changed gdbstub in way
that debugging 32 or 16-bit guest code is no longer possible with qemu
for x86_64 guest CPUs. Since that commit, qemu only provides registers
sets for 64-bit, forcing current and foreseeable gdb to also switch its
architecture to 64-bit. And this breaks if the inferior is 32 or 16 bit.
No question, this is a gdb issue. But, as it was confirmed in several
discusssions with gdb people, it is a non-trivial thing to fix. So until
qemu finds a gdb version attach with a rework x86 support, we have to
work around it by switching the register layout as the guest switches
its execution mode between 16/32 and 64 bit.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Sent to qemu-kvm for inclusion on Avi's request as this workaround is
still disliked upstream.
Note: qemu-kvm's gdbstub support in kvm mode is currently borken in git
- I'm bisecting...
gdbstub.c | 55 -
target-i386/cpu.h |7 +--
2 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index c9304cd..a33aba0 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -506,8 +506,9 @@ static const int gpr_map[16] = {
8, 9, 10, 11, 12, 13, 14, 15
};
#else
-static const int gpr_map[8] = {0, 1, 2, 3, 4, 5, 6, 7};
+#define gpr_map gpr_map32
#endif
+static const int gpr_map32[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
#define NUM_CORE_REGS (CPU_NB_REGS * 2 + 25)
@@ -521,7 +522,11 @@ static const int gpr_map[8] = {0, 1, 2, 3, 4, 5, 6, 7};
static int cpu_gdb_read_register(CPUState *env, uint8_t *mem_buf, int n)
{
if (n CPU_NB_REGS) {
-GET_REGL(env-regs[gpr_map[n]]);
+if (TARGET_LONG_BITS == 64 env-hflags HF_CS64_MASK) {
+GET_REG64(env-regs[gpr_map[n]]);
+} else if (n CPU_NB_REGS32) {
+GET_REG32(env-regs[gpr_map32[n]]);
+}
} else if (n = IDX_FP_REGS n IDX_FP_REGS + 8) {
#ifdef USE_X86LDOUBLE
/* FIXME: byteswap float values - after fixing fpregs layout. */
@@ -532,12 +537,20 @@ static int cpu_gdb_read_register(CPUState *env, uint8_t
*mem_buf, int n)
return 10;
} else if (n = IDX_XMM_REGS n IDX_XMM_REGS + CPU_NB_REGS) {
n -= IDX_XMM_REGS;
-stq_p(mem_buf, env-xmm_regs[n].XMM_Q(0));
-stq_p(mem_buf + 8, env-xmm_regs[n].XMM_Q(1));
-return 16;
+if (n CPU_NB_REGS32 ||
+(TARGET_LONG_BITS == 64 env-hflags HF_CS64_MASK)) {
+stq_p(mem_buf, env-xmm_regs[n].XMM_Q(0));
+stq_p(mem_buf + 8, env-xmm_regs[n].XMM_Q(1));
+return 16;
+}
} else {
switch (n) {
-case IDX_IP_REG:GET_REGL(env-eip);
+case IDX_IP_REG:
+if (TARGET_LONG_BITS == 64 env-hflags HF_CS64_MASK) {
+GET_REG64(env-eip);
+} else {
+GET_REG32(env-eip);
+}
case IDX_FLAGS_REG: GET_REG32(env-eflags);
case IDX_SEG_REGS: GET_REG32(env-segs[R_CS].selector);
@@ -593,8 +606,15 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t
*mem_buf, int n)
uint32_t tmp;
if (n CPU_NB_REGS) {
-env-regs[gpr_map[n]] = ldtul_p(mem_buf);
-return sizeof(target_ulong);
+if (TARGET_LONG_BITS == 64 env-hflags HF_CS64_MASK) {
+env-regs[gpr_map[n]] = ldtul_p(mem_buf);
+return sizeof(target_ulong);
+} else if (n CPU_NB_REGS32) {
+n = gpr_map32[n];
+env-regs[n] = ~0xUL;
+env-regs[n] |= (uint32_t)ldl_p(mem_buf);
+return 4;
+}
} else if (n = IDX_FP_REGS n IDX_FP_REGS + 8) {
#ifdef USE_X86LDOUBLE
/* FIXME: byteswap float values - after fixing fpregs layout. */
@@ -603,14 +623,23 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t
*mem_buf, int n)
return 10;
} else if (n = IDX_XMM_REGS n IDX_XMM_REGS + CPU_NB_REGS) {
n -= IDX_XMM_REGS;
-env-xmm_regs[n].XMM_Q(0) = ldq_p(mem_buf);
-env-xmm_regs[n].XMM_Q(1) = ldq_p(mem_buf + 8);
-return 16;
+if (n CPU_NB_REGS32 ||
+(TARGET_LONG_BITS == 64 env-hflags HF_CS64_MASK)) {
+env-xmm_regs[n].XMM_Q(0) = ldq_p(mem_buf);
+env-xmm_regs[n].XMM_Q(1) = ldq_p(mem_buf + 8);
+return 16;
+}
} else {
switch (n) {
case IDX_IP_REG:
-env-eip = ldtul_p(mem_buf);
-return sizeof(target_ulong);
+if (TARGET_LONG_BITS == 64 env-hflags HF_CS64_MASK) {
+env-eip = ldq_p(mem_buf);
+return 8;
+} else {
+env-eip = ~0xUL;
+env-eip |= (uint32_t)ldl_p(mem_buf);
+return 4;
+}
case IDX_FLAGS_REG:
env-eflags = ldl_p(mem_buf);
return 4;
diff --git a/target-i386/cpu.h
Re: [PATCH] virtio-blk: set QUEUE_ORDERED_DRAIN by default
Err, I'll take this one back for now pending some more discussion. What we need more urgently is the writeback cache flag, which is now implemented in qemu, patch following ASAP. -- 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 network latency, higher with virtio ?
On Wed, Sep 16, 2009 at 11:47:07AM +0300, Dor Laor wrote: Hi! Thank you for explaining. Measurements of older versions of virtio proved that we can cancel this timer and achieve better latency while not hurting throughput. Well, I did try the patch Michael is suggesting here: http://lkml.org/lkml/2009/8/17/140 And I should say that in my testing environment not only the throughput doesn't decrease, but in some cases it grows (tested using netperf with udp-stream). Vhost wouldn't use it. For the time being until be get vhost, we should probably remove it from qemu. Yes please, check with your tests and consider this. Thank you, Luca -- 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] qemu-kvm: Fix guest single-stepping
Hopefully the last regression of 4c0960c0: KVM_SET_GUEST_DEBUG requires
properly synchronized guest registers (on x86: eflags) on entry.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-kvm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 78eeb6f..569397e 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -2282,6 +2282,10 @@ static void kvm_invoke_set_guest_debug(void *data)
{
struct kvm_set_guest_debug_data *dbg_data = data;
+if (cpu_single_env-kvm_cpu_state.regs_modified) {
+kvm_arch_put_registers(cpu_single_env);
+cpu_single_env-kvm_cpu_state.regs_modified = 0;
+}
dbg_data-err =
kvm_set_guest_debug(cpu_single_env-kvm_cpu_state.vcpu_ctx,
dbg_data-dbg);
--
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: [ANNOUNCE] Release to community: Windows kvm/virtio guest drivers
The sources are released and can be easily compiled :) Some technical issues with releasing the binaries. But they are coming soon. Best regards, Yan. -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Armindo Silva Sent: Thursday, September 17, 2009 7:05 PM To: Yan Vugenfirer Cc: Chris Howells; kvm@vger.kernel.org Subject: Re: [ANNOUNCE] Release to community: Windows kvm/virtio guest drivers Hi, There are any news about the new pv drivers? They would be very welcome by the community :) Cheers Armindo On Mon, Aug 17, 2009 at 4:03 PM, Yan Vugenfirer yvuge...@redhat.com wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Chris Howells Sent: Monday, August 17, 2009 5:18 PM To: kvm@vger.kernel.org Subject: Re: [ANNOUNCE] Release to community: Windows kvm/virtio guest drivers Hi, On Mon, August 17, 2009 2:21 pm, Yan Vugenfirer wrote: I am happy to announce the release of the Windows kvm/virtio guest drivers to open source community under GPLv2 license! Wiki: http://www.linux-kvm.org/page/WindowsGuestDrivers Thanks for these, they look very interesting. Unfortunately the download links appear to be broken. I followed the download link at http://www.linux- kvm.org/page/WindowsGuestDrivers/Last_WHQLed_drivers but when I click media:viostor.tar it prompts me to upload a file. Thanks [YV] Soon I will post the MS signed binaries. -- 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 -- -- The only way of discovering the limits of the possible is to venture a little way past them into the impossible. Sir Arthur C. Clarke -- 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
[PATCH] update qemu-ifup for modern ip route output
update qemu-ifup for modern ip route output
The output from the /sbin/ip utility has changed, adding two
more columns, which breaks the qemu-ifup script, as it was
depending on the last column being the interface name.
Change this from $NF to $5.
https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/430652
Signed-off-by: Dustin Kirkland kirkl...@canonical.com
---
kvm/scripts/qemu-ifup |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kvm/scripts/qemu-ifup b/kvm/scripts/qemu-ifup
index 3bf8801..284b176 100755
--- a/kvm/scripts/qemu-ifup
+++ b/kvm/scripts/qemu-ifup
@@ -1,5 +1,5 @@
#!/bin/sh
-switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
+switch=$(/sbin/ip route list | awk '/^default / { print $5 }')
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif ${switch} $1
--
1.6.3.3
signature.asc
Description: This is a digitally signed message part
Re: [PATCH -v2] QEMU-KVM: MCE: Relay UCR MCE to guest
On Thu, Sep 17, 2009 at 09:13:29AM +0800, Huang Ying wrote:
On Thu, 2009-09-17 at 01:59 +0800, Marcelo Tosatti wrote:
On Wed, Sep 09, 2009 at 10:28:02AM +0800, Huang Ying wrote:
UCR (uncorrected recovery) MCE is supported in recent Intel CPUs,
where some hardware error such as some memory error can be reported
without PCC (processor context corrupted). To recover from such MCE,
the corresponding memory will be unmapped, and all processes accessing
the memory will be killed via SIGBUS.
For KVM, if QEMU/KVM is killed, all guest processes will be killed
too. So we relay SIGBUS from host OS to guest system via a UCR MCE
injection. Then guest OS can isolate corresponding memory and kill
necessary guest processes only. SIGBUS sent to main thread (not VCPU
threads) will be broadcast to all VCPU threads as UCR MCE.
v2:
- Use qemu_ram_addr_from_host instead of self made one to covert from
host address to guest RAM address. Thanks Anthony Liguori.
Signed-off-by: Huang Ying ying.hu...@intel.com
---
cpu-common.h |1
exec.c| 20 +--
qemu-kvm.c| 154
++
target-i386/cpu.h | 20 ++-
4 files changed, 178 insertions(+), 17 deletions(-)
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -27,10 +27,23 @@
#include sys/mman.h
#include sys/ioctl.h
#include signal.h
+#include sys/signalfd.h
+#include sys/prctl.h
#define false 0
#define true 1
+#ifndef PR_MCE_KILL
+#define PR_MCE_KILL 33
+#endif
+
+#ifndef BUS_MCEERR_AR
+#define BUS_MCEERR_AR 4
+#endif
+#ifndef BUS_MCEERR_AO
+#define BUS_MCEERR_AO 5
+#endif
+
#define EXPECTED_KVM_API_VERSION 12
#if EXPECTED_KVM_API_VERSION != KVM_API_VERSION
@@ -1507,6 +1520,37 @@ static void sig_ipi_handler(int n)
{
}
+static void sigbus_handler(int n, struct signalfd_siginfo *siginfo, void
*ctx)
+{
+if (siginfo-ssi_code == BUS_MCEERR_AO) {
+uint64_t status;
+unsigned long paddr;
+CPUState *cenv;
+
+/* Hope we are lucky for AO MCE */
+if (do_qemu_ram_addr_from_host((void *)siginfo-ssi_addr,
paddr)) {
+fprintf(stderr, Hardware memory error for memory used by
+QEMU itself instead of guest system!: %llx\n,
+(unsigned long long)siginfo-ssi_addr);
+return;
qemu-kvm should die here?
There are two kinds of UCR MCE. One is triggered by user space/guest
read/write, the other is triggered by asynchronously detected error
(e.g. patrol scrubbing). The latter one is reported as AO (Action
Optional) MCE, and it has nothing to do with current path. So if we are
lucky enough, we can survive. And when we finally touch the error memory
reported by AO MCE, another AR (Action Required) MCE will be triggered.
We have another chance to deal with it.
OK.
+}
+status = MCI_STATUS_VAL | MCI_STATUS_UC | MCI_STATUS_EN
+| MCI_STATUS_MISCV | MCI_STATUS_ADDRV | MCI_STATUS_S
+| 0xc0;
+kvm_inject_x86_mce(first_cpu, 9, status,
+ MCG_STATUS_MCIP | MCG_STATUS_RIPV, paddr,
+ (MCM_ADDR_PHYS 6) | 0xc);
+for (cenv = first_cpu-next_cpu; cenv != NULL; cenv =
cenv-next_cpu)
+kvm_inject_x86_mce(cenv, 1, MCI_STATUS_VAL | MCI_STATUS_UC,
+ MCG_STATUS_MCIP | MCG_STATUS_RIPV, 0, 0);
+return;
Should abort if kvm_inject_x86_mce fails?
kvm_inject_x86_mce will abort by itself.
OK.
+} else if (siginfo-ssi_code == BUS_MCEERR_AR)
+fprintf(stderr, Hardware memory error!\n);
+else
+fprintf(stderr, Internal error in QEMU!\n);
Can you re-raise SIGBUS so you we get a coredump on non-MCE SIGBUS as
usual?
We discuss this before. Copied below, please comment the comments
below, :)
Avi:
(also, I if we can't handle guest-mode SIGBUS I think it would be nice
to raise it again so the process terminates due to the SIGBUS).
Huang Ying:
For SIGBUS we can not relay to guest as MCE, we can either abort or
reset SIGBUS to SIGDFL and re-raise it. Both are OK for me. You prefer
the latter one?
Andi:
I think a suitable error message and exit would be better than a plain
signal kill. It shouldn't look like qemu crashed due to a software
bug. Ideally a error message in a way that it can be parsed by libvirt
etc. and reported in a suitable way.
However qemu getting killed itself is very unlikely, it doesn't
have much memory foot print compared to the guest and other data.
So this should be a very rare condition.
Avi:
libvirt etc. can/should wait() for qemu to terminate abnormally and
report the reason why. However it doesn't seem there is a
Re: losing mouse location with vnc
On Sat, 2009-09-12 at 11:48 +0200, Kenni Lund wrote: 2009/9/12 Ross Boylan r...@biostat.ucsf.edu: When I try to use a (Linux) VM via vnc there appear to be two mouse locations at once. One is the pointer displayed on the screen; the other is the shown as a little box by krdc when I select always show local cursor in the krdc menu. It also appears when I use xtightvncviewer. Try using -usbdevice tablet as an argument to the QEMU/KVM executable, it will most likely fix your problem. Thank you for the suggestion. Unfortunately, it doesn't seem to make a difference. Here's how I invoked it: sudo vdeq kvm -net nic,vlan=1,macaddr=52:54:a0:14:01:01 \ -name Lenny BCU Server \ -serial file:kvm.log \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -boot c \ -vnc :6 -usbdevice tablet \ -hda /dev/turtle/Lenny06BCU \ -soundhw es1370 -m 1G -smp 2 kvm 72+dfsg-5~lenny2 on a 2.6.26 kernel. Ross -- 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
Possible problem with -no-kvm-irqchip -no-kvm-pit qemu options detected during git daily testing
Hi folks, after looking at today's git testing results, it seems like we have a problem with the command line options: -no-kvm-irqchip -no-kvm-pit All VMs that started with those command line options just hang on the BIOS screen, therefore all tests failed due to timeouts. So this looks like a real issue that needs to be looked at. If someone wants to look at the results in order to investigate the issues, the commit hashes of the git trees used are: 09/17 00:57:41 INFO | kvm_utils:0182| Commit hash for git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git is 852a3e8725b7672e36d29609538b232e7ea80b53 (v2.6.31-rc3-8224-g852a3e8) 09/17 00:58:03 INFO | kvm_utils:0182| Commit hash for git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is 561d3ed34ece750609c2dcb8e432668d672c42f7 (kvm-88-1081-g561d3ed) 09/17 00:58:04 INFO | kvm_utils:0182| Commit hash for git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git is e9f6d366fa77a0988bcba2554a63a539ff1b2358 (kvm-88-14-ge9f6d36) The full command lines being used are: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor unix:/tmp/monitor-20090917-005904-H8Zl,server,nowait -drive file=/usr/local/autotest/tests/kvm/images/fc9-32.qcow2,if=ide,boot=on -net nic,vlan=0 -net user,vlan=0 -m 512 -cdrom /usr/local/autotest/tests/kvm/isos/linux/Fedora-9-i386-DVD.iso -smp 2 -no-kvm-irqchip -no-kvm-pit -redir tcp:5000::22 -vnc :0 /usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor unix:/tmp/monitor-20090917-005904-H8Zl,server,nowait -drive file=/usr/local/autotest/tests/kvm/images/fc9-64.qcow2,if=ide,boot=on -net nic,vlan=0 -net user,vlan=0 -m 512 -cdrom /usr/local/autotest/tests/kvm/isos/linux/Fedora-9-x86_64-DVD.iso -smp 2 -no-kvm-irqchip -no-kvm-pit -redir tcp:5000::22 -vnc :0 /usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor unix:/tmp/monitor-20090917-005904-H8Zl,server,nowait -drive file=/usr/local/autotest/tests/kvm/images/win2008-64.qcow2,if=ide,boot=on -net nic,vlan=0 -net user,vlan=0 -m 512 -cdrom /usr/local/autotest/tests/kvm/isos/windows/Windows2008-x64.iso -smp 2 -no-kvm-irqchip -no-kvm-pit -redir tcp:5000::23 -vnc :0 Please let me know if you need more information about the failures. Lucas -- 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 9/9] KVM: remove duplicated #include
Applied, thanks.
On Wed, Sep 16, 2009 at 09:09:39PM +0800, Huang Weiyi wrote:
Remove duplicated #include('s) in
arch/x86/kvm/lapic.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
arch/x86/kvm/lapic.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 1ae5ceb..1fa20c4 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -32,7 +32,6 @@
#include asm/current.h
#include asm/apicdef.h
#include asm/atomic.h
-#include asm/apicdef.h
#include kvm_cache_regs.h
#include irq.h
#include trace.h
--
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 -v2] QEMU-KVM: MCE: Relay UCR MCE to guest
On Fri, 2009-09-18 at 05:36 +0800, Marcelo Tosatti wrote: +} else if (siginfo-ssi_code == BUS_MCEERR_AR) +fprintf(stderr, Hardware memory error!\n); +else +fprintf(stderr, Internal error in QEMU!\n); Can you re-raise SIGBUS so you we get a coredump on non-MCE SIGBUS as usual? We discuss this before. Copied below, please comment the comments below, :) Avi: (also, I if we can't handle guest-mode SIGBUS I think it would be nice to raise it again so the process terminates due to the SIGBUS). Huang Ying: For SIGBUS we can not relay to guest as MCE, we can either abort or reset SIGBUS to SIGDFL and re-raise it. Both are OK for me. You prefer the latter one? Andi: I think a suitable error message and exit would be better than a plain signal kill. It shouldn't look like qemu crashed due to a software bug. Ideally a error message in a way that it can be parsed by libvirt etc. and reported in a suitable way. However qemu getting killed itself is very unlikely, it doesn't have much memory foot print compared to the guest and other data. So this should be a very rare condition. Avi: libvirt etc. can/should wait() for qemu to terminate abnormally and report the reason why. However it doesn't seem there is a way to get extended signal information from wait(), so it looks like internal handling by qemu is better. I'm not talking about SIGBUS generated by MCE. What i mean is, for SIGBUS signals that are not due to MCE errors, the current behaviour is to generate a core dump (which is useful information for debugging). With your patch, qemu-kvm handles the signal, prints a message before exiting. This is annoying. It seems the discussion above is about SIGBUS initiated by MCE errors. OK. I will re-raise for SIGBUS not initiated by MCE. Best Regards, Huang Ying -- 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
whats the advantage of enable-io-thread
Hi all, what is the advantage of the --enable-io-thread options. It is disabled by default - why? - Dietmar -- 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: option -daemonize broken in -next branch of qemu-kvm
On Fri, Sep 18, 2009 at 02:15:12AM +1000, renev...@netspace.net.au wrote: Hello, When using -daemonize the VM won't start and the following is printed: kvm_create_vcpu: Input/output error create_userspace_phys_mem: Input/output error kvm_cpu_register_physical_memory: failed Regards, Will Trives Fixed, thanks. -- 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
