Linux-next changes for module and virtio trees.
Hi Stephen, Please remove my quilt tree http://ozlabs.org/~rusty/kernel/rr-latest/ from linux-next, and use my git trees from now on: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git Branches: modules-next virtio-next For others: beware that these will rebase, usually once after the merge window closes (so I can work on a more modern tree), and again just before it opens (where I squash in fixup patches). Cheers, Rusty. -- 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] kvm: Set default accelerator to kvm if the host supports it
Daniel P. Berrange berra...@redhat.com writes: On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas Färber wrote: Hello Jan, Am 01.10.2012 16:34, schrieb Jan Kiszka: If we built a target for a host that supports KVM in principle, set the default accelerator to KVM as well. This also means the start of QEMU will fail to start if KVM support turns out to be unavailable at runtime. From a distro point of view this of course means that we will build against KVM and that the new KVM default will start to fail for users on very old hardware. Can't we do a runtime check to select the default? NB, this is *not* only about old hardware. There are plenty of users who use QEMU inside VMs. One very common usage I know of is image building tools which are run inside Amazon VMs, using libguestfs QEMU. IMHO, default to KVM, fallback to TCG is the most friendly default behaviour. Friendly perhaps, generating an infinite series of questions why is my guest slow as molasses? certainly. And for each instance of the question, there's an unknown number of users who give QEMU a quick try, screw up KVM unknowingly, observe the glacial speed, and conclude it's crap. -- 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-kvm: remove boot=on|off drive parameter compatibility
On Mon, Oct 01, 2012 at 08:19:29AM -0500, Anthony Liguori wrote: Jan Kiszka jan.kis...@siemens.com writes: I think at this point, none of this matters but I added the various distro maintainers to the thread. I think it's time for the distros to drop qemu-kvm and just ship qemu.git. Is there anything else that needs to happen to make that switch? If that is upstream's recommendation, then I see no issue with switching Fedora 19 / RHEL-7 to use qemu.git instead of qemu-kvm.git. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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 0/2] virtio-scsi fixes for 3.6
On Mon, 2012-10-01 at 15:11 +0200, Paolo Bonzini wrote: Il 26/07/2012 15:28, Paolo Bonzini ha scritto: James, patch 1 fixes scanning of LUNs whose number is greater than 255. QEMU passes a max_lun of 16383 (because it uses SAM numbering) but in Linux it must become 32768 (because LUNs above 255 are relocated to 16640). Patch 2 is a resubmission of the patch for online resizing of virtio-scsi LUNs, which needs to be rebased. LUNs above 255 now work for all of scanning, hotplug, hotunplug and resize. Thanks, Paolo Paolo Bonzini (2): virtio-scsi: fix LUNs greater than 255 virtio-scsi: support online resizing of disks drivers/scsi/virtio_scsi.c | 37 +++-- include/linux/virtio_scsi.h |2 ++ 2 files changed, 37 insertions(+), 2 deletions(-) Ping, are these patches going into 3.7? They're 3.7 candidates yes (enhancements certainly aren't 3.6). I seem to have become lost with the virtio-scsi updates since what I have marked for inclusion is a patch series that's a partial intersection with this. I'll flush my queue for virto-scsi, please resend all the missing patches you want in 3.7. Thanks, James -- 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: vga passthrough // questions about pci passthrough
Hello, would a Memory Dump from inside the VM help solving the BSOD, or is that pointless? Thank you for your patience and help ;) Am 28.09.2012 18:29, schrieb Jan Kiszka: On 2012-09-28 17:50, Alex Williamson wrote: On Fri, 2012-09-28 at 10:12 +0200, Jan Kiszka wrote: On 2012-09-27 21:18, Alex Williamson wrote: On Thu, 2012-09-27 at 20:43 +0200, Martin Wolf wrote: thank you for the information. i will try what you mentioned... do you have some additional information about rebooting a VM with a passed through videocard? (amd / ati 7870) I don't. Is the bsod on reboot only or does it also happen on shutdown? There's a slim chance it could be traced by enabling debug in the pci-assign driver and analyzing what the guest driver is trying to do. I'm hoping that q35 chipset support might resolve some issues with vga assignment as it exposes a topology that looks a bit more like one that a driver would expect on physical hardware. Thanks, From our attempts to get more working than what NVIDIA Quadro cards support officially, my own experiments with q35 in this context and our discussions with NVIDIA, I'm pretty skeptical that this chipset will make a difference here. Most problems are due to those non-standard side channels to configure the hardware, memory mappings etc. And getting this working requires either cooperation of the vendor or *a lot* of reverse engineering. I heard from an nvidia guy that the driver behaves differently depending on whether it finds an upstream express port, so we're probably causing ourselves more problems if it's trying to run in AGP mode. May be a point for the low- to mid-range cards. It does not apply to the virtualization-ready Quadro series according to our information back then. There was also a lot of FUD in Xen (maybe justified) around how the BIOS determines the memory ranges and whether it bypasses the PCI BARs and gets them directly. That means some cards may require identity mapping to work. It seems like the very high-end cards are possibly fixing this, but they're far more expensive than I can justify. Thanks, Yes, that is what makes them virtualization ready. But they also come with limitations. So far, you can't pass-through a primary card or use it for early boot messages of the guest as the BIOS is not ready for that - without identity mapping or even more. Jan -- Adiumentum GmbH Gf. Martin Wolf Banderbacherstraße 76 90513 Zirndorf 0911 / 9601470 mw...@adiumentum.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: [Qemu-devel] Block Migration and xbzrle
Orit Wasserman wrote: On 09/16/2012 01:39 PM, Peter Lieven wrote: Hi, I remember that this was broken some time ago and currently with qemu-kvm 1.2.0 I am still not able to use block migration plus xbzrle. The migration fails if both are used together. XBZRLE without block migration works. Can someone please advise what is the current expected behaviour? XBZRLE only work on guest memory so it shouldn't be effected by block migration. What is the error you are getting? What command line ? Meanwhile I can confirm that it happens with and without block migration. I I observe 2 errors: a) qemu: warning: error while loading state section id 2 load of migration failed b) the vm does not enter running state after migration. The command-line: /usr/bin/qemu-kvm-1.2.0 -net tap,vlan=798,script=no,downscript=no,ifname=tap1 -net nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15 -drive format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native -m 4096 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait -name 'Ubuntu-Tools' -boot order=dc,menu=off -k de -incoming tcp:172.21.55.34:5002 -pidfile /var/run/qemu/vm-250.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU L5640 @ 2.27GHz',-tsc Thanks, Peter Regards, Orit Thanks, Peter -- 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 0/2] virtio-scsi fixes for 3.6
Il 02/10/2012 10:18, James Bottomley ha scritto: On Mon, 2012-10-01 at 15:11 +0200, Paolo Bonzini wrote: Il 26/07/2012 15:28, Paolo Bonzini ha scritto: James, patch 1 fixes scanning of LUNs whose number is greater than 255. QEMU passes a max_lun of 16383 (because it uses SAM numbering) but in Linux it must become 32768 (because LUNs above 255 are relocated to 16640). Patch 2 is a resubmission of the patch for online resizing of virtio-scsi LUNs, which needs to be rebased. LUNs above 255 now work for all of scanning, hotplug, hotunplug and resize. Thanks, Paolo Paolo Bonzini (2): virtio-scsi: fix LUNs greater than 255 virtio-scsi: support online resizing of disks drivers/scsi/virtio_scsi.c | 37 +++-- include/linux/virtio_scsi.h |2 ++ 2 files changed, 37 insertions(+), 2 deletions(-) Ping, are these patches going into 3.7? They're 3.7 candidates yes (enhancements certainly aren't 3.6). I seem to have become lost with the virtio-scsi updates since what I have marked for inclusion is a patch series that's a partial intersection with this. I'll flush my queue for virto-scsi, please resend all the missing patches you want in 3.7. Ok, will do so soon and tag the appropriate ones for stable. Paolo -- 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 08/10] ARM: KVM: VGIC initialisation code
On Mon, Oct 01, 2012 at 10:14:26AM +0100, Christoffer Dall wrote: From: Marc Zyngier marc.zyng...@arm.com Add the init code for the hypervisor, the virtual machine, and the virtual CPUs. An interrupt handler is also wired to allow the VGIC maintenance interrupts, used to deal with level triggered interrupts and LR underflows. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Christoffer Dall c.d...@virtualopensystems.com --- [...] diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c index b52d4c2..fc2a138 100644 --- a/arch/arm/kvm/vgic.c +++ b/arch/arm/kvm/vgic.c @@ -20,7 +20,14 @@ #include linux/kvm_host.h #include linux/interrupt.h #include linux/io.h +#include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h + #include asm/kvm_emulate.h +#include asm/hardware/gic.h +#include asm/kvm_arm.h +#include asm/kvm_mmu.h /* * How the whole thing works (courtesy of Christoffer Dall): @@ -61,6 +68,13 @@ /* Temporary hacks, need to be provided by userspace emulation */ #define VGIC_DIST_BASE 0x2c001000 #define VGIC_DIST_SIZE 0x1000 +#define VGIC_CPU_BASE0x2c002000 +#define VGIC_CPU_SIZE0x2000 We really don't want the physical memory map for the guest hardwired in the kernel. Please find a way to parameterise this from userspace. Will -- 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] Block Migration and xbzrle
On 10/02/2012 10:33 AM, lieven-li...@dlh.net wrote: Orit Wasserman wrote: On 09/16/2012 01:39 PM, Peter Lieven wrote: Hi, I remember that this was broken some time ago and currently with qemu-kvm 1.2.0 I am still not able to use block migration plus xbzrle. The migration fails if both are used together. XBZRLE without block migration works. Can someone please advise what is the current expected behaviour? XBZRLE only work on guest memory so it shouldn't be effected by block migration. What is the error you are getting? What command line ? Meanwhile I can confirm that it happens with and without block migration. I I observe 2 errors: a) qemu: warning: error while loading state section id 2 load of migration failed b) the vm does not enter running state after migration. The command-line: /usr/bin/qemu-kvm-1.2.0 -net tap,vlan=798,script=no,downscript=no,ifname=tap1 -net nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15 -drive format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native -m 4096 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait -name 'Ubuntu-Tools' -boot order=dc,menu=off -k de -incoming tcp:172.21.55.34:5002 -pidfile /var/run/qemu/vm-250.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU Migration with -cpu host is very problemtic, because the source and destination can have different cpu resulting in different cpu features. Does regular migration works with this setup? Can you try with a different cpu type? What are the source and destination /proc/cpuinfo output ? Cheers, Orit L5640 @ 2.27GHz',-tsc Thanks, Peter Regards, Orit Thanks, Peter -- 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] Block Migration and xbzrle
Am 02.10.2012 um 11:28 schrieb Orit Wasserman: On 10/02/2012 10:33 AM, lieven-li...@dlh.net wrote: Orit Wasserman wrote: On 09/16/2012 01:39 PM, Peter Lieven wrote: Hi, I remember that this was broken some time ago and currently with qemu-kvm 1.2.0 I am still not able to use block migration plus xbzrle. The migration fails if both are used together. XBZRLE without block migration works. Can someone please advise what is the current expected behaviour? XBZRLE only work on guest memory so it shouldn't be effected by block migration. What is the error you are getting? What command line ? Meanwhile I can confirm that it happens with and without block migration. I I observe 2 errors: a) qemu: warning: error while loading state section id 2 load of migration failed b) the vm does not enter running state after migration. The command-line: /usr/bin/qemu-kvm-1.2.0 -net tap,vlan=798,script=no,downscript=no,ifname=tap1 -net nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15 -drive format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native -m 4096 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait -name 'Ubuntu-Tools' -boot order=dc,menu=off -k de -incoming tcp:172.21.55.34:5002 -pidfile /var/run/qemu/vm-250.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU Migration with -cpu host is very problemtic, because the source and destination can have different cpu resulting in different cpu features. Does regular migration works with this setup? Can you try with a different cpu type? What are the source and destination /proc/cpuinfo output ? The CPUs are identical, we also check if flags and cpu types match if cpu type is set to host. Regular migration does work. BR, Peter Cheers, Orit L5640 @ 2.27GHz',-tsc Thanks, Peter Regards, Orit Thanks, Peter -- 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: Block Migration and xbzrle
Il 16/09/2012 12:39, Peter Lieven ha scritto: I remember that this was broken some time ago and currently with qemu-kvm 1.2.0 I am still not able to use block migration plus xbzrle. The migration fails if both are used together. XBZRLE without block migration works. Can someone please advise what is the current expected behaviour? Block migration is broken by design. It will converge really slowly as soon as you have real load in the VMs, and it will hamper the convergence of RAM as well. Hopefully a real alternative will be in 1.3 (based on drive-mirror on the source + an embedded NBD server running on the destination), then in 1.4 we can reimplement the block migration monitor commands using the alternative. Paolo -- 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] kvm: Set default accelerator to kvm if the host supports it
On Tue, Oct 02, 2012 at 09:46:12AM +0200, Markus Armbruster wrote: Daniel P. Berrange berra...@redhat.com writes: On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas Färber wrote: Hello Jan, Am 01.10.2012 16:34, schrieb Jan Kiszka: If we built a target for a host that supports KVM in principle, set the default accelerator to KVM as well. This also means the start of QEMU will fail to start if KVM support turns out to be unavailable at runtime. From a distro point of view this of course means that we will build against KVM and that the new KVM default will start to fail for users on very old hardware. Can't we do a runtime check to select the default? NB, this is *not* only about old hardware. There are plenty of users who use QEMU inside VMs. One very common usage I know of is image building tools which are run inside Amazon VMs, using libguestfs QEMU. IMHO, default to KVM, fallback to TCG is the most friendly default behaviour. Friendly perhaps, generating an infinite series of questions why is my guest slow as molasses? certainly. And for each instance of the question, there's an unknown number of users who give QEMU a quick try, screw up KVM unknowingly, observe the glacial speed, and conclude it's crap. That's why it should not fallback silently to TCG, but warn the user about that. On the other hand, on a machine without KVM support (which might just be because of local policy admin policy which doesn't provide access the /dev/kvm, nested virtualization, etc.), if QEMU fails to start (while previous versions were working), the user can conclude that QEMU is crap. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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: Block Migration and xbzrle
Am 02.10.2012 um 11:38 schrieb Paolo Bonzini: Il 16/09/2012 12:39, Peter Lieven ha scritto: I remember that this was broken some time ago and currently with qemu-kvm 1.2.0 I am still not able to use block migration plus xbzrle. The migration fails if both are used together. XBZRLE without block migration works. Can someone please advise what is the current expected behaviour? Block migration is broken by design. It will converge really slowly as soon as you have real load in the VMs, and it will hamper the convergence of RAM as well. Hopefully a real alternative will be in 1.3 (based on drive-mirror on the source + an embedded NBD server running on the destination), then in 1.4 we can reimplement the block migration monitor commands using the alternative. Hi Paolo, i know that block migration is not that good, but it seems that there is a bug in XBZRLE that is independent of block migration. Peter Paolo -- 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: Block Migration and xbzrle
Il 02/10/2012 11:44, Peter Lieven ha scritto: Am 02.10.2012 um 11:38 schrieb Paolo Bonzini: Il 16/09/2012 12:39, Peter Lieven ha scritto: I remember that this was broken some time ago and currently with qemu-kvm 1.2.0 I am still not able to use block migration plus xbzrle. The migration fails if both are used together. XBZRLE without block migration works. Can someone please advise what is the current expected behaviour? Block migration is broken by design. It will converge really slowly as soon as you have real load in the VMs, and it will hamper the convergence of RAM as well. Hopefully a real alternative will be in 1.3 (based on drive-mirror on the source + an embedded NBD server running on the destination), then in 1.4 we can reimplement the block migration monitor commands using the alternative. Hi Paolo, i know that block migration is not that good, but it seems that there is a bug in XBZRLE that is independent of block migration. Understood---but hopefully you can stop using it with 1.3, which would also work around the bug. :) Paolo -- 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/2] KVM: PPC: e500: fix allocation size error on g2h_tlb1_map
On 10/01/2012 12:59 PM, Alexander Graf wrote: On 30.09.2012, at 13:29, Avi Kivity wrote: On 09/27/2012 09:59 PM, Alexander Graf wrote: Do you have the auto-autotest setup ready? I guess we can do it manually until it is. I do have a local autotest setup. Or what exactly are you referring to? Getting autotest to run automatically and produce readable reports, and auto-bisection. I'm not quite there yet :). Do you have any precooked things I could reuse? Nope, currently we eat from the tin. -- 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 v2 08/10] ARM: KVM: VGIC initialisation code
On Tue, 2 Oct 2012 10:24:13 +0100, Will Deacon will.dea...@arm.com wrote: On Mon, Oct 01, 2012 at 10:14:26AM +0100, Christoffer Dall wrote: From: Marc Zyngier marc.zyng...@arm.com Add the init code for the hypervisor, the virtual machine, and the virtual CPUs. An interrupt handler is also wired to allow the VGIC maintenance interrupts, used to deal with level triggered interrupts and LR underflows. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Christoffer Dall c.d...@virtualopensystems.com --- [...] diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c index b52d4c2..fc2a138 100644 --- a/arch/arm/kvm/vgic.c +++ b/arch/arm/kvm/vgic.c @@ -20,7 +20,14 @@ #include linux/kvm_host.h #include linux/interrupt.h #include linux/io.h +#include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h + #include asm/kvm_emulate.h +#include asm/hardware/gic.h +#include asm/kvm_arm.h +#include asm/kvm_mmu.h /* * How the whole thing works (courtesy of Christoffer Dall): @@ -61,6 +68,13 @@ /* Temporary hacks, need to be provided by userspace emulation */ #define VGIC_DIST_BASE 0x2c001000 #define VGIC_DIST_SIZE 0x1000 +#define VGIC_CPU_BASE 0x2c002000 +#define VGIC_CPU_SIZE 0x2000 We really don't want the physical memory map for the guest hardwired in the kernel. Please find a way to parameterise this from userspace. Yes, this is a known problem. KVM doesn't offer a standard way of passing the address of an interrupt controller (none of the other architectures have it memory mapped). We probably need a separate ioctl for that... M. -- Fast, cheap, reliable. Pick two. -- 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] Block Migration and xbzrle
On 10/02/2012 11:30 AM, Peter Lieven wrote: Am 02.10.2012 um 11:28 schrieb Orit Wasserman: On 10/02/2012 10:33 AM, lieven-li...@dlh.net wrote: Orit Wasserman wrote: On 09/16/2012 01:39 PM, Peter Lieven wrote: Hi, I remember that this was broken some time ago and currently with qemu-kvm 1.2.0 I am still not able to use block migration plus xbzrle. The migration fails if both are used together. XBZRLE without block migration works. Can someone please advise what is the current expected behaviour? XBZRLE only work on guest memory so it shouldn't be effected by block migration. What is the error you are getting? What command line ? Meanwhile I can confirm that it happens with and without block migration. I I observe 2 errors: a) qemu: warning: error while loading state section id 2 load of migration failed Did you enabled XBZRLE on the destination also? (migrate_set_capability xbzrle on) Orit b) the vm does not enter running state after migration. The command-line: /usr/bin/qemu-kvm-1.2.0 -net tap,vlan=798,script=no,downscript=no,ifname=tap1 -net nic,vlan=798,model=e1000,macaddr=52:54:00:ff:01:15 -drive format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-d85f4e007-3f30017ce11505df-ubuntu-tools-hd0,if=virtio,cache=none,aio=native -m 4096 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4002,server,nowait -vnc :2 -qmp tcp:0:3002,server,nowait -name 'Ubuntu-Tools' -boot order=dc,menu=off -k de -incoming tcp:172.21.55.34:5002 -pidfile /var/run/qemu/vm-250.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu host,+x2apic,model_id='Intel(R) Xeon(R) CPU Migration with -cpu host is very problemtic, because the source and destination can have different cpu resulting in different cpu features. Does regular migration works with this setup? Can you try with a different cpu type? What are the source and destination /proc/cpuinfo output ? The CPUs are identical, we also check if flags and cpu types match if cpu type is set to host. Regular migration does work. BR, Peter Cheers, Orit L5640 @ 2.27GHz',-tsc Thanks, Peter Regards, Orit Thanks, Peter -- 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: [PATCH 3/6] arch/powerpc/kvm/e500_tlb.c: fix error return code
On 05.08.2012, at 11:52, Julia Lawall wrote:
From: Julia Lawall ju...@diku.dk
Convert a 0 error return code to a negative one, as returned elsewhere in the
function.
A new label is also added to avoid freeing things that are known to not yet
be allocated.
A simplified version of the semantic match that finds the first problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
Thanks, applied to kvm-ppc-next.
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
KVM call minutes 2012-10-02
2012-10-02 -- - TODO to finish off qemu-kvm.git/master... (anthony) posibilibites: Problems of compatability (options, migration, ...) * configuration file to specify what versions are done * scripts that converts the format * documentation * look at argv[0] and start from there giving warnings changing options, and we ship a symlink. Anthony: rename: pc-0.12 to qemu-pc-0.12 and the qemu-kvm ones as kvm-pc-0.12 and create alias depending on argv[0] for instance. - cpu-hotplug status? developers want - migration changes for migration format. they are compatible, but default machines are not. - vga framebuffer size is 16MB, and can't be changed upstream have already configurability for this - tasks: compatability of options migration compatibility anthony offers to do the machine compatibility thing -- 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 memory leak?
Hi list, I have a CentOS 5.7 / kvm-88-3.el5.x86_64 and it gets at 99.9% mem used. I'm not able to explain all memory usage nor identify what is consuming all the memory. I've lost 100GB of memory that it's not being identified on procs RSS, slab structures. I really appreciate If somebody can give me a hint on this I paste some data of the server: Total running procs rss = 45593328 #cat /proc/meminfo MemTotal: 198092704 kB MemFree: 6181724 kB Buffers:113624 kB Cached:2350212 kB SwapCached: 97512 kB Active: 45768944 kB Inactive: 2281996 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 198092704 kB LowFree: 6181724 kB SwapTotal: 1015800 kB SwapFree: 267780 kB Dirty: 100624 kB Writeback: 32 kB AnonPages:45512440 kB Mapped: 16584 kB Slab: 307768 kB PageTables: 102492 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit: 100062152 kB Committed_AS: 50353508 kB VmallocTotal: 34359738367 kB VmallocUsed:364532 kB VmallocChunk: 34359337427 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 Hugepagesize: 2048 kB #cat /proc/cpuinfo [only last proc] processor : 23 vendor_id : GenuineIntel cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz stepping: 2 cpu MHz : 3066.884 cache size : 12288 KB physical id : 0 siblings: 12 core id : 1 cpu cores : 6 apicid : 3 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx pdpe1gb rdtscp lm constant_tsc ida nonstop_tsc arat pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm bogomips: 6133.52 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: [8] /dev/shm uses grew to 100Gb, but actually it's using 0% of it, and this should not reflect on memory usage #df|grep shm tmpfs 99046352 0 99046352 0% /dev/shm Kernel #uname -a Linux server 2.6.18-238.9.1.el5 #1 SMP Tue Apr 12 18:10:13 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux OS: Centos 5.7 KVM rpms version kmod-kvm-83-224.el5.centos.1.x86_64 kvm-88-3.el5.x86_64\ qemu is 0.10 thank you Sergio -- If you end up with a boring, miserable life because you listened to your mom, your dad, your teacher, your priest, or some guy on television telling you how to do your shit, then you deserve it. Frank Zappa -- 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 0/3] s390/kvm: misc fixes
Avi, Marcelo, here are some fixes for kvm on s390. Would be good if we could add s390/kvm: dont announce RRBM support for 3.7 since the current kvm claims a feature that we currently dont support. Everything else can be queued for the next merge window. Thanks Christian Borntraeger (1): s390/kvm: dont announce RRBM support Cornelia Huck (1): s390/kvm: Add documentation for KVM_S390_INTERRUPT. Jason J. Herne (1): s390/kvm: Interrupt injection bugfix Documentation/virtual/kvm/api.txt | 33 + arch/s390/kvm/interrupt.c | 19 ++- arch/s390/kvm/kvm-s390.c | 2 +- 3 files changed, 52 insertions(+), 2 deletions(-) -- 1.7.11.7 -- 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/3] s390/kvm: dont announce RRBM support
Newer kernels (linux-next with the transparent huge page patches) use rrbm if the feature is announced via feature bit 66. RRBM will cause intercepts, so KVM does not handle it right now, causing an illegal instruction in the guest. The easy solution is to disable the feature bit for the guest. This fixes bugs like: Kernel BUG at 00124c2a [verbose debug info unavailable] illegal operation: 0001 [#1] SMP Modules linked in: virtio_balloon virtio_net ipv6 autofs4 CPU: 0 Not tainted 3.5.4 #1 Process fmempig (pid: 659, task: 7b712fd0, ksp: 7bed3670) Krnl PSW : 0704d0018000 00124c2a (pmdp_clear_flush_young+0x5e/0x80) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3 003cc000 0004 7980 0004 7bed3918 7cf4 0001 03fff7f0 03d281a94000 7bed383c 7bed3918 005ecbf8 002314a6 7bed36e0 Krnl Code:00124c2a: b9810025 ogr %r2,%r5 00124c2e: 41343000 la %r3,0(%r4,%r3) 00124c32: a716fffa brct%r1,124c26 00124c36: b9010022 lngr%r2,%r2 00124c3a: e3d0f084 lg %r13,128(%r15) 00124c40: eb22003f000c srlg%r2,%r2,63 [ 2150.713198] Call Trace: [ 2150.713223] ([002312c4] page_referenced_one+0x6c/0x27c) [ 2150.713749] [00233812] page_referenced+0x32a/0x410 [...] CC: sta...@vger.kernel.org CC: Alex Graf ag...@suse.de Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com --- arch/s390/kvm/kvm-s390.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index ecced9d..38883f0 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -997,7 +997,7 @@ static int __init kvm_s390_init(void) } memcpy(facilities, S390_lowcore.stfle_fac_list, 16); facilities[0] = 0xff00fff3f47cULL; - facilities[1] = 0x201cULL; + facilities[1] = 0x001cULL; return 0; } -- 1.7.11.7 -- 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 1/3] s390/kvm: Interrupt injection bugfix
From: Jason J. Herne jjhe...@us.ibm.com
EXTERNAL_CALL and EMERGENCY type interrupts need to preserve their interrupt
code parameter when being injected from user space.
Signed-off-by: Jason J. Herne jjhe...@us.ibm.com
Reviewed-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/interrupt.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 7556231..744ac1b 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -631,10 +631,27 @@ int kvm_s390_inject_vcpu(struct kvm_vcpu *vcpu,
break;
case KVM_S390_SIGP_STOP:
case KVM_S390_RESTART:
+ VCPU_EVENT(vcpu, 3, inject: type %x, s390int-type);
+ inti-type = s390int-type;
+ break;
case KVM_S390_INT_EXTERNAL_CALL:
+ if (s390int-parm 0x) {
+ kfree(inti);
+ return -EINVAL;
+ }
+ VCPU_EVENT(vcpu, 3, inject: external call source-cpu:%u,
+ s390int-parm);
+ inti-type = s390int-type;
+ inti-extcall.code = s390int-parm;
+ break;
case KVM_S390_INT_EMERGENCY:
- VCPU_EVENT(vcpu, 3, inject: type %x, s390int-type);
+ if (s390int-parm 0x) {
+ kfree(inti);
+ return -EINVAL;
+ }
+ VCPU_EVENT(vcpu, 3, inject: emergency %u\n, s390int-parm);
inti-type = s390int-type;
+ inti-emerg.code = s390int-parm;
break;
case KVM_S390_INT_VIRTIO:
case KVM_S390_INT_SERVICE:
--
1.7.11.7
--
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 2/3] s390/kvm: Add documentation for KVM_S390_INTERRUPT.
From: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
Documentation/virtual/kvm/api.txt | 33 +
1 file changed, 33 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 36befa7..c58 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1984,6 +1984,39 @@ return the hash table order in the parameter. (If the
guest is using
the virtualized real-mode area (VRMA) facility, the kernel will
re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.)
+4.77 KVM_S390_INTERRUPT
+
+Capability: basic
+Archtectures: s390
+Type: vm ioctl, vcpu ioctl
+Parameters: struct kvm_s390_interrupt (in)
+Returns: 0 on success, -1 on error
+
+Allows to inject an interrupt to the guest. Interrupts can be floating
+(vm ioctl) or per cpu (vcpu ioctl), depending on the interrupt type.
+
+Interrupt parameters are passed via kvm_s390_interrupt:
+
+struct kvm_s390_interrupt {
+ __u32 type;
+ __u32 parm;
+ __u64 parm64;
+};
+
+type can be one of the following:
+
+KVM_S390_SIGP_STOP (vcpu) - sigp restart
+KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm
+KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm
+KVM_S390_RESTART (vcpu) - restart
+KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt
+ parameters in parm and parm64
+KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm
+KVM_S390_INT_EMERGENCY (vcpu) - sigp emergency; source cpu in parm
+KVM_S390_INT_EXTERNAL_CALL (vcpu) - sigp external call; source cpu in parm
+
+Note that the vcpu ioctl is asynchronous to vpcu execution.
+
5. The kvm_run structure
--
1.7.11.7
--
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: resize raw images
On Fri, Sep 28, 2012 at 6:14 PM, Lentes, Bernd bernd.len...@helmholtz-muenchen.de wrote: I also have to create some new vm's. What is when disk space is running out ? My idea is to create the new vm's in raw images. Inside the vm, filesystems will reside in logical volumes. When disk space is running out, i resize the raw image using: - qemu-img create -f raw additional.raw size - cat additional.raw vm.raw - inside the vm, resize the filesystems easily with lvm tools und resize2fs. You don't need to create and concatenate an empty raw image file. To grow the raw image file in a single step: $ qemu-img resize test.img +10G This only grows the virtual disk size. Inside the guest you still need to resize partitions, logical volumes, and file systems like you mentioned. 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] virtio-blk: Disable callback in virtblk_done()
On Thu, Sep 27, 2012 at 12:01 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 27/09/2012 02:10, Rusty Russell ha scritto:
+do {
+virtqueue_disable_cb(vq);
+while ((vbr = virtqueue_get_buf(vblk-vq, len)) !=
NULL) {
+if (vbr-bio) {
+virtblk_bio_done(vbr);
+bio_done = true;
+} else {
+virtblk_request_done(vbr);
+req_done = true;
+}
}
-}
+} while (!virtqueue_enable_cb(vq));
/* In case queue is stopped waiting for more buffers. */
if (req_done)
blk_start_queue(vblk-disk-queue);
Fascinating. Please just confirm that VIRTIO_RING_F_EVENT_IDX is
enabled?
Yeah, it's a nice and cheap trick. Stefan, I see that you had this in
virtio-scsi since even before I picked it up. Do you remember how you
came up with it?
I've played with disable_cb/enable_cb previously in virtio-blk and
virtio-scsi when aliguori had suggested reducing notifies. I
definitely didn't invent it :).
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: Linux-next changes for module and virtio trees.
Hi Rusty, On Tue, 02 Oct 2012 15:56:56 +0930 Rusty Russell ru...@rustcorp.com.au wrote: Please remove my quilt tree http://ozlabs.org/~rusty/kernel/rr-latest/ from linux-next, and use my git trees from now on: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git Branches: modules-next virtio-next Done. For others: beware that these will rebase, usually once after the merge window closes (so I can work on a more modern tree), and again just before it opens (where I squash in fixup patches). The first should not be necessary since everything in these trees should have been merged by Linus during the merge window, so a merge of -rc1 or later should be a fast forward (though merging with the tag itself may produce a real merge). The second can be tricky to pick the right moment :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpcWF6h5n5N0.pgp Description: PGP signature
Re: Block live migration without pausing VM
On Sun, Sep 23, 2012 at 5:03 PM, Felix Leimbach felix.leimb...@gmail.com wrote: I want to implement live-migration of a highly available VM but I cannot use shared storage. The -b option to the migrate command already allows for copying the block device (locally stored raw file) and that is exactly what I want. This worked in my experiments but the VM is unreachable (CPU halted?) while the block device is copied, which is unacceptable for my use-case. Is there a way to copy the block device while the VM is running (copy on read or such)? The LiveBlockMigration page in the qemu wiki [1] mentions that some of this is already implemented, but I cannot find any of it in the latest qemu-kvm. Any pointers? You can live migrate storage - either to move image files to a new file system on the same host or before/after live migration - using the QMP block-stream command. See QEMU's ./qapi-schema.json for documentation on the block streaming commands. Libvirt exposes this command as blockpull. Copying happens in the background while the VM is running. Note that image streaming is orthogonal to guest live migration, you need to do it either before or after (probably onto an NFS export). 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 v2 08/10] ARM: KVM: VGIC initialisation code
On Oct 2, 2012, at 6:25 AM, Marc Zyngier marc.zyng...@arm.com wrote: On Tue, 2 Oct 2012 10:24:13 +0100, Will Deacon will.dea...@arm.com wrote: On Mon, Oct 01, 2012 at 10:14:26AM +0100, Christoffer Dall wrote: From: Marc Zyngier marc.zyng...@arm.com Add the init code for the hypervisor, the virtual machine, and the virtual CPUs. An interrupt handler is also wired to allow the VGIC maintenance interrupts, used to deal with level triggered interrupts and LR underflows. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Christoffer Dall c.d...@virtualopensystems.com --- [...] diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c index b52d4c2..fc2a138 100644 --- a/arch/arm/kvm/vgic.c +++ b/arch/arm/kvm/vgic.c @@ -20,7 +20,14 @@ #include linux/kvm_host.h #include linux/interrupt.h #include linux/io.h +#include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h + #include asm/kvm_emulate.h +#include asm/hardware/gic.h +#include asm/kvm_arm.h +#include asm/kvm_mmu.h /* * How the whole thing works (courtesy of Christoffer Dall): @@ -61,6 +68,13 @@ /* Temporary hacks, need to be provided by userspace emulation */ #define VGIC_DIST_BASE0x2c001000 #define VGIC_DIST_SIZE0x1000 +#define VGIC_CPU_BASE0x2c002000 +#define VGIC_CPU_SIZE0x2000 We really don't want the physical memory map for the guest hardwired in the kernel. Please find a way to parameterise this from userspace. Yes, this is a known problem. KVM doesn't offer a standard way of passing the address of an interrupt controller (none of the other architectures have it memory mapped). We probably need a separate ioctl Thoughts on how to make this API flexible enough? Can we somehow provide a device tree to the host kernel, which would be the same device tree the guest uses, which may also describe virtio features, or is this completely sci fi? -Christoffer-- 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: [kvmarm] [PATCH v2 08/10] ARM: KVM: VGIC initialisation code
On 2 October 2012 18:55, Christoffer Dall c.d...@virtualopensystems.com wrote: On Oct 2, 2012, at 6:25 AM, Marc Zyngier marc.zyng...@arm.com wrote: On Tue, 2 Oct 2012 10:24:13 +0100, Will Deacon will.dea...@arm.com We really don't want the physical memory map for the guest hardwired in the kernel. Please find a way to parameterise this from userspace. Yes, this is a known problem. KVM doesn't offer a standard way of passing the address of an interrupt controller (none of the other architectures have it memory mapped). We probably need a separate ioctl Thoughts on how to make this API flexible enough? Can we somehow provide a device tree to the host kernel, which would be the same device tree the guest uses, which may also describe virtio features, or is this completely sci fi? I'm not really in favour of trying to shoehorn device trees in here (among other things, the virtual machine we create should be the actual machine matching the hardware, not something randomly generated from the device tree. Also requiring userspace to manufacture a device tree from scratch is kind of awkward: there's no reason the guest has to be using one, and it's a lot of effort to go to to pass a single address into the kernel...) We probably want to be passing in the base of the cpu-internal peripherals, rather than base of the GIC specifically. For the A15 these are the same thing, but that's not inherent [compare the A9 which has more devices at fixed offsets from a configurable base address]. On hardware this is done by having an input signal that's sampled at reset that tells the CPU where the peripherals are; is there an equivalent of that for any other CPU properties that we have already in the KVM API? -- PMM -- 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: [kvmarm] [PATCH v2 08/10] ARM: KVM: VGIC initialisation code
On Tue, Oct 02, 2012 at 07:31:43PM +0100, Peter Maydell wrote: We probably want to be passing in the base of the cpu-internal peripherals, rather than base of the GIC specifically. For the A15 these are the same thing, but that's not inherent [compare the A9 which has more devices at fixed offsets from a configurable base address]. If you do that, userspace will need a way to probe the emulated CPU so that is knows exactly which set of peripherals there are and which ones it needs to emulate. This feels pretty nasty, given that the vgic is handled more or less completely by the kernel-side of things. Will -- 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: [kvmarm] [PATCH v2 08/10] ARM: KVM: VGIC initialisation code
On 2 October 2012 20:28, Will Deacon will.dea...@arm.com wrote: On Tue, Oct 02, 2012 at 07:31:43PM +0100, Peter Maydell wrote: We probably want to be passing in the base of the cpu-internal peripherals, rather than base of the GIC specifically. For the A15 these are the same thing, but that's not inherent [compare the A9 which has more devices at fixed offsets from a configurable base address]. If you do that, userspace will need a way to probe the emulated CPU so that is knows exactly which set of peripherals there are and which ones it needs to emulate. This feels pretty nasty, given that the vgic is handled more or less completely by the kernel-side of things. Userspace knows what the emulated CPU is because it tells the kernel which CPU to provide -- the kernel can say yes or no but it can't provide a different CPU to the one we ask for, or one with bits mising... -- PMM -- 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/2] KVM: PPC: e500: fix allocation size error on g2h_tlb1_map
On 10/01/2012 12:59 PM, Alexander Graf wrote: On 30.09.2012, at 13:29, Avi Kivity wrote: On 09/27/2012 09:59 PM, Alexander Graf wrote: Do you have the auto-autotest setup ready? I guess we can do it manually until it is. I do have a local autotest setup. Or what exactly are you referring to? Getting autotest to run automatically and produce readable reports, and auto-bisection. I'm not quite there yet :). Do you have any precooked things I could reuse? Nope, currently we eat from the tin. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc 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/6] arch/powerpc/kvm/e500_tlb.c: fix error return code
On 05.08.2012, at 11:52, Julia Lawall wrote:
From: Julia Lawall ju...@diku.dk
Convert a 0 error return code to a negative one, as returned elsewhere in the
function.
A new label is also added to avoid freeing things that are known to not yet
be allocated.
A simplified version of the semantic match that finds the first problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
Thanks, applied to kvm-ppc-next.
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
