Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
* Anthony Liguori wrote: > It's important to understand why one mechanism is better than another. All > I'm looking for is a set of bullet points that say, vbus does this, > vhost-net does that, therefore vbus is better. We would then either say, > oh, that's a good idea, let's change vhost-net to do that, or we would say, > hrm, well, we can't change vhost-net to do that because of some fundamental > flaw, let's drop it and adopt vbus. > > It's really that simple :-) That makes a lot of sense to me. I think we better have damn good technical reasons before we encourage a fork of a subsystem within the kernel. Technical truth is not something we can 'agree to disagree' on, and it is not something we can compromise on really. Both the host and the guest code is in Linux so adding another variant without that variant replacing the old one (on the spot or gradually) makes no technical sense. Gregory, i'd suggest for you to shape this as a "this and this aspect of KVM needs to be replaced/fixed" list of items, as suggested by Anthony. In my experience the KVM folks are very approachable and very reasonable about addressing technical shortcomings and acting upon feedback (and are happily accepting code as well) - so to the extent there's room for improvement here it should be done by shaping KVM, not by forking and rebranding it. Ingo -- 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 vs Qemu-KVM
On 12/22/2009 12:21 AM, Mikolaj Kucharski wrote: On Mon, Dec 21, 2009 at 09:22:52AM +0200, Gleb Natapov wrote: I have personal interest in resolving RedHat's bz #508801, unfortunately I cannot do that myself, so I wanted to ask on the list for help, but now I'm confused where should I go. Can you try kvm modules from latest kvm.git please? It looks like emulation of "push %ds" fails and it was added after 2.6.32. Having following GIT repositories: git://git.kernel.org/pub/scm/virt/kvm/kvm.git git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git Which one I should use to build my modules from? I would like to keep my system (Fedora 12) consistent and I don't want to have any parts built outside of rpm. I would like to contribute/help for RedHat's bz #508801 resolution, but I need some directions. git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git git submodule init git submodule update ./configure make sync make make install Is kvm.git whole Linux kernel Yes. kvm-kmod downloads it (via git submodule) and extracts the kvm bits (via make sync). -- 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: requested regions overlap, rom loading failed using -kernel
On 12/22/2009 04:12 AM, Marco Schinkel wrote: Hi, after upgrading from qemu-kvm-0.11.1 to 0.12.1 i get the following error starting my kvm (guest is linux 2.6.32): rom: requested regions overlap (rom linuxboot.bin. free=0x2300, addr=0x) rom loading failed I have no -drive option and no -boot option, only -kernel This worked without problems in previous kvm versions. I assume the IDE controller has an option rom which supplies a boot drive and the linuxboot "option rom" does the same. BTW: The VM boots from network. Actually I dont need the IDE controller at all. How can I disable it? I've fixed this for qemu-kvm-0.12.1.1. -- 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 0/3] Improve Decrementor Implementation v2
On 12/21/2009 09:21 PM, Alexander Graf wrote: We currently have an ugly hack called AGGRESSIVE_DEC that makes the Decrementor either work well for PPC32 or PPC64 targets. This patchset removes that hack, bringing the decrementor implementation closer to real hardware. Applied, thanks. -- 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] Show KVM timing option only on embedded
On 12/20/2009 11:24 PM, Alexander Graf wrote: Embedded PowerPC KVM has an exit timing implementation to track and evaluate how much time was spent in which exit path. For Book3S, we don't implement it. So let's not expose it as a config option either. Applied, thanks. -- 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] Change PowerPC KVM maintainer
On 12/20/2009 11:24 PM, Alexander Graf wrote: Progress on KVM for Embedded PowerPC has stalled, but for Book3S there's quite a lot of work to do and going on. So in agreement with Hollis and Avi, we should switch maintainers for PowerPC. I'll still demand Acks from Hollis for code that changes BookE parts when I can't say for sure if the change is ok. Applied, thanks. -- 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 0/3] Device Assignment fixes
On 12/17/2009 05:04 PM, Alexander Graf wrote: While trying out I stumbled across several issues in the device assignment code. This set addresses the most major ones. Namely allowing passthrough of non page aligned BAR region (like on lpfc) and telling users what to do when their device is in use. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] slow_map: minor improvements to ROM BAR handling
ROM BAR can be handled same as regular BAR: load_option_roms utility will take care of copying it to RAM as appropriate. Signed-off-by: Michael S. Tsirkin --- This patch applies on top of agraf's one, it takes care of non-page aligned ROM BARs as well: they mostly are taken care of, we just do not need to warn user about them. hw/device-assignment.c | 20 +--- 1 files changed, 9 insertions(+), 11 deletions(-) diff --git a/hw/device-assignment.c b/hw/device-assignment.c index 000fa61..066fdb6 100644 --- a/hw/device-assignment.c +++ b/hw/device-assignment.c @@ -486,25 +486,23 @@ static int assigned_dev_register_regions(PCIRegion *io_regions, : PCI_BASE_ADDRESS_SPACE_MEMORY; if (cur_region->size & 0xFFF) { -fprintf(stderr, "PCI region %d at address 0x%llx " -"has size 0x%x, which is not a multiple of 4K. " -"You might experience some performance hit due to that.\n", -i, (unsigned long long)cur_region->base_addr, -cur_region->size); +if (i != PCI_ROM_SLOT) { +fprintf(stderr, "PCI region %d at address 0x%llx " +"has size 0x%x, which is not a multiple of 4K. " +"You might experience some performance hit " +"due to that.\n", +i, (unsigned long long)cur_region->base_addr, +cur_region->size); +} slow_map = 1; } -if (slow_map && (i == PCI_ROM_SLOT)) { -fprintf(stderr, "ROM not aligned - can't continue\n"); -return -1; -} - /* map physical memory */ pci_dev->v_addrs[i].e_physbase = cur_region->base_addr; if (i == PCI_ROM_SLOT) { pci_dev->v_addrs[i].u.r_virtbase = mmap(NULL, - (cur_region->size + 0xFFF) & 0xF000, + cur_region->size, PROT_WRITE | PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, 0, (off_t) 0); -- 1.6.6.rc1.43.gf55cc -- 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] vhost: fix high 32 bit in FEATURES ioctls
From: David Stevens Subject: vhost: fix high 32 bit in FEATURES ioctls VHOST_GET_FEATURES fails to initialize high-order 32 bits in the returned value, and VHOST_SET_FEATURES fails to check them. This patch fixes it to use 64 bits throughout. Signed-off-by: David L Stevens Signed-off-by: Michael S. Tsirkin --- Rusty, can you queue this for 2.6.33 as well please? diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 22d5fef..d6db10c 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -563,7 +563,7 @@ static long vhost_net_ioctl(struct file *f, unsigned int ioctl, { struct vhost_net *n = f->private_data; void __user *argp = (void __user *)arg; - u32 __user *featurep = argp; + u64 __user *featurep = argp; struct vhost_vring_file backend; u64 features; int r; @@ -575,10 +575,9 @@ static long vhost_net_ioctl(struct file *f, unsigned int ioctl, return vhost_net_set_backend(n, backend.index, backend.fd); case VHOST_GET_FEATURES: features = VHOST_FEATURES; - return put_user(features, featurep); + return copy_to_user(featurep, &features, sizeof features); case VHOST_SET_FEATURES: - r = get_user(features, featurep); - /* No features for now */ + r = copy_from_user(&features, featurep, sizeof features); if (r < 0) return r; if (features & ~VHOST_FEATURES) -- 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: [GIT PULL] AlacrityVM guest drivers for 2.6.33
Anthony Liguori writes: > > On a modern Nehalem, I would be surprised if an MMIO exit handled in > the kernel was muck more than 2us. The hardware is getting very, very > fast. The trends here are very important to consider when we're > looking at architectures that we potentially are going to support for > a long time. When you talk about trends the trend for IO is also to get faster. An exit will be always more expensive than passing something from another CPU in shared memory. An exit is much more work, with lots of saved context and fundamentally synchronous, even with all the tricks hardware can do. And then there's the in kernel handler too. Shared memory passing from another CPU is a much cheaper operation and more likely to scale with IO rate improvements. The basic problem in this discussion seems to be the usual disconnect between working code (I understand Gregory has working code that demonstrates the performance advances he's claiming) versus unwritten optimizations. Unwritten code tends to always sound nicer, but it remains to be seen if it can deliver what it promises. >From a abstract stand point having efficient paravirtual IO interfaces seem attractive. I also personally don't see a big problem in having another set of virtual drivers -- Linux already has plenty (vmware, xen, virtio, power, s390-vm, ...) and it's not that they would be a particular maintenance burden impacting the kernel core. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
qemu-kvm-0.12 bug?
Hi, I've switched from -0.11.0 to -0.12 and from 2.6.31.6 to 2.6.32.2 to try the new virtio-memory-API introduced in latest libvirt from git. I can start VMs f.e. by kvm -cdrom $someiso --enable-kvm but my domain configs to not work anymore. Domain config: http://pastebin.com/f66324669 Qemu log when doing "virsh start wp01": LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.11 -enable-kvm -m 1000 -smp 1 -name wp01 -uuid 4c34e9aa-2bcd-fa8e-bc98-4417c1cb779a -chardev socket,id=monitor,path=/usr/local/var/lib/libvirt/qemu/wp01.monitor,server,nowait -monitor chardev:monitor -boot c -kernel /boot/vmlinuz-2.6.32.2 -initrd /boot/initrd.img-2.6.32.2 -append root=/dev/vdb noresume2 -drive file=/dev/disk/by-path/ip-10.0.1.1:3260-iscsi-iqn.2009-09.local:store.wp01-swap-lun-0,if=virtio,index=0,boot=on -drive file=/dev/disk/by-path/ip-10.0.1.1:3260-iscsi-iqn.2009-09.local:store.wp01-disk-lun-0,if=virtio,index=1 -net nic,macaddr=00:16:3e:00:01:01,vlan=0,model=virtio,name=virtio.0 -net tap,fd=18,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 0.0.0.0:0 -k de -vga cirrus char device redirected to /dev/pts/3 Option 'ipv4': Use 'on' or 'off' Failed to parse "yes" for "dummy.ipv4" rom: requested regions overlap (rom vapic.bin. free=0x0600, addr=0x) rom loading failed Is this a bug or am I missing something? Thanks, kr tom -- 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] slow_map: minor improvements to ROM BAR handling
Michael S. Tsirkin wrote: > ROM BAR can be handled same as regular BAR: > load_option_roms utility will take care of > copying it to RAM as appropriate. > > Signed-off-by: Michael S. Tsirkin > --- > > This patch applies on top of agraf's one, > it takes care of non-page aligned ROM BARs as well: > they mostly are taken care of, we just do not > need to warn user about them. > > hw/device-assignment.c | 20 +--- > 1 files changed, 9 insertions(+), 11 deletions(-) > > diff --git a/hw/device-assignment.c b/hw/device-assignment.c > index 000fa61..066fdb6 100644 > --- a/hw/device-assignment.c > +++ b/hw/device-assignment.c > @@ -486,25 +486,23 @@ static int assigned_dev_register_regions(PCIRegion > *io_regions, > : PCI_BASE_ADDRESS_SPACE_MEMORY; > > if (cur_region->size & 0xFFF) { > -fprintf(stderr, "PCI region %d at address 0x%llx " > -"has size 0x%x, which is not a multiple of 4K. " > -"You might experience some performance hit due to > that.\n", > -i, (unsigned long long)cur_region->base_addr, > -cur_region->size); > +if (i != PCI_ROM_SLOT) { > +fprintf(stderr, "PCI region %d at address 0x%llx " > +"has size 0x%x, which is not a multiple of 4K. " > +"You might experience some performance hit " > +"due to that.\n", > +i, (unsigned long long)cur_region->base_addr, > +cur_region->size); > +} > slow_map = 1; > This is wrong. You're setting slow_map = 1 on code that is very likely to be executed inside the guest. That doesn't work. Better pad the ROM size to page boundary and use the shadow mapping we have in place already. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm-0.12 bug?
On Tuesday 22 December 2009 13:02:28 Thomas Treutner wrote: > Hi, > > I've switched from -0.11.0 to -0.12 and from 2.6.31.6 to 2.6.32.2 to try > the new virtio-memory-API introduced in latest libvirt from git. I can > start VMs f.e. by kvm -cdrom $someiso --enable-kvm but my domain configs to > not work anymore. Just found the other bug report about this -- 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] slow_map: minor improvements to ROM BAR handling
On Tue, Dec 22, 2009 at 01:05:23PM +0100, Alexander Graf wrote: > Michael S. Tsirkin wrote: > > ROM BAR can be handled same as regular BAR: > > load_option_roms utility will take care of > > copying it to RAM as appropriate. > > > > Signed-off-by: Michael S. Tsirkin > > --- > > > > This patch applies on top of agraf's one, > > it takes care of non-page aligned ROM BARs as well: > > they mostly are taken care of, we just do not > > need to warn user about them. > > > > hw/device-assignment.c | 20 +--- > > 1 files changed, 9 insertions(+), 11 deletions(-) > > > > diff --git a/hw/device-assignment.c b/hw/device-assignment.c > > index 000fa61..066fdb6 100644 > > --- a/hw/device-assignment.c > > +++ b/hw/device-assignment.c > > @@ -486,25 +486,23 @@ static int assigned_dev_register_regions(PCIRegion > > *io_regions, > > : PCI_BASE_ADDRESS_SPACE_MEMORY; > > > > if (cur_region->size & 0xFFF) { > > -fprintf(stderr, "PCI region %d at address 0x%llx " > > -"has size 0x%x, which is not a multiple of 4K. " > > -"You might experience some performance hit due to > > that.\n", > > -i, (unsigned long long)cur_region->base_addr, > > -cur_region->size); > > +if (i != PCI_ROM_SLOT) { > > +fprintf(stderr, "PCI region %d at address 0x%llx " > > +"has size 0x%x, which is not a multiple of 4K. > > " > > +"You might experience some performance hit " > > +"due to that.\n", > > +i, (unsigned long long)cur_region->base_addr, > > +cur_region->size); > > +} > > slow_map = 1; > > > > This is wrong. You're setting slow_map = 1 on code that is very likely > to be executed inside the guest. That doesn't work. It is? Can you really run code directly from a PCI card? I looked at BIOS boot specification and it always talks about shadowing PCI ROMs. > Better pad the ROM size to page boundary and use the shadow mapping we > have in place already. Changing BAR size might break some drivers. Our BIOS seems to shadow ROM instead of running it directly, so we should be fine I think? > > 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
[ANNOUNCE] qemu-kvm-0.12.1.1
qemu-kvm-0.12.1.1 is now available. This release is is based on the upstream qemu 0.12.1, plus kvm-specific enhancements. Please see the original qemu 0.12.1 release announcement for details. This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.32. Changes from qemu-kvm-0.12.1 - fix build error due to missing kvm_save_mpstate() on some configurations - fix option rom loading (fixes boot=on) http://www.linux-kvm.org -- 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
Soft lockups and cpu frequency scaling
All, I'm running a manually compiled KVM on CentOS 5.4. The KVM installation has been carried over from CentOS 5.3, when KVM wasn't distributed with the OS. (I tried to migrate to CentOS 5.4 native KVM support, but wasn't able to get along with RedHat's interpretation of KVM.) The KVM version used is 88, on Kernel 2.6.18-128.7.1.el5, as KVM doesn't seem to compile on CentOS' current 2.6.18-164.9.1.el5. Only on CentOS guests, I see very frequent "soft lockup" messages and excessively hanging KVM instances. Long-term stability is fine (several months uptime), but disturbed by the hangs. The problem already was there on CentOS 5.3 as well. With the Debian guests on the same host, I have never had any apparent problems. A number of google results suggest that I should work with CPU scaling on the CentOS guest systems, but unfortunately, CPU scaling is not available in my guests. So, here's my question: How do I enable CPU scaling in KVM guests? Or is there any other measure against these soft lockups that you can recommend? Thanks everyone, -martin -- Martin Schmitt / Schmitt Systemberatung / www.scsy.de --> http://www.pug.org/index.php/Benutzer:Martin <-- -- 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] qemu-kvm-0.12.1.1
sorry to bring bad news, but it still doesn't compile (at least for me): [r...@vmdev03 qemu-kvm-0.12.1.1]# make LINK x86_64-softmmu/qemu-system-x86_64 machine.o: In function `cpu_pre_save': /usr/src/redhat/BUILD/qemu-kvm-0.12.1.1/target-i386/machine.c:326: undefined reference to `kvm_save_mpstate' collect2: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 n. On Tue, Dec 22, 2009 at 02:50:03PM +0200, Avi Kivity wrote: > qemu-kvm-0.12.1.1 is now available. This release is is based on the > upstream qemu 0.12.1, plus kvm-specific enhancements. Please see > the original qemu 0.12.1 release announcement for details. > > This release can be used with the kvm kernel modules provided by > your distribution kernel, or by the modules in the kvm-kmod package, > such as kvm-kmod-2.6.32. > > Changes from qemu-kvm-0.12.1 > - fix build error due to missing kvm_save_mpstate() on some configurations > - fix option rom loading (fixes boot=on) > > > http://www.linux-kvm.org > > -- > 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 > -- - Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - -- 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] slow_map: minor improvements to ROM BAR handling
Michael S. Tsirkin wrote: > On Tue, Dec 22, 2009 at 01:05:23PM +0100, Alexander Graf wrote: > >> Michael S. Tsirkin wrote: >> >>> ROM BAR can be handled same as regular BAR: >>> load_option_roms utility will take care of >>> copying it to RAM as appropriate. >>> >>> Signed-off-by: Michael S. Tsirkin >>> --- >>> >>> This patch applies on top of agraf's one, >>> it takes care of non-page aligned ROM BARs as well: >>> they mostly are taken care of, we just do not >>> need to warn user about them. >>> >>> hw/device-assignment.c | 20 +--- >>> 1 files changed, 9 insertions(+), 11 deletions(-) >>> >>> diff --git a/hw/device-assignment.c b/hw/device-assignment.c >>> index 000fa61..066fdb6 100644 >>> --- a/hw/device-assignment.c >>> +++ b/hw/device-assignment.c >>> @@ -486,25 +486,23 @@ static int assigned_dev_register_regions(PCIRegion >>> *io_regions, >>> : PCI_BASE_ADDRESS_SPACE_MEMORY; >>> >>> if (cur_region->size & 0xFFF) { >>> -fprintf(stderr, "PCI region %d at address 0x%llx " >>> -"has size 0x%x, which is not a multiple of 4K. " >>> -"You might experience some performance hit due to >>> that.\n", >>> -i, (unsigned long long)cur_region->base_addr, >>> -cur_region->size); >>> +if (i != PCI_ROM_SLOT) { >>> +fprintf(stderr, "PCI region %d at address 0x%llx " >>> +"has size 0x%x, which is not a multiple of 4K. >>> " >>> +"You might experience some performance hit " >>> +"due to that.\n", >>> +i, (unsigned long long)cur_region->base_addr, >>> +cur_region->size); >>> +} >>> slow_map = 1; >>> >>> >> This is wrong. You're setting slow_map = 1 on code that is very likely >> to be executed inside the guest. That doesn't work. >> > > It is? Can you really run code directly from a PCI card? > I looked at BIOS boot specification and it always talks > about shadowing PCI ROMs. > I'm not sure the BIOS is the only one executing ROMs. If it is, then I'm good with the change. Maybe it'd make sense to also add a read only flag so we don't accidently try to write to the ROM region with slow_map. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] qemu-kvm-0.12.1.1
On 12/22/2009 03:35 PM, Nikola Ciprich wrote: sorry to bring bad news, but it still doesn't compile (at least for me): [r...@vmdev03 qemu-kvm-0.12.1.1]# make LINK x86_64-softmmu/qemu-system-x86_64 machine.o: In function `cpu_pre_save': /usr/src/redhat/BUILD/qemu-kvm-0.12.1.1/target-i386/machine.c:326: undefined reference to `kvm_save_mpstate' collect2: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 Please provide details about your host. -- 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: [ANNOUNCE] qemu-kvm-0.12.1.1
CentOS5, all packages updated. But I just noticed build fails only when configured with multiple targets, including some more exotic (based on fedora spec). building just using x86_64-softmmu works fine for me. n. On Tue, Dec 22, 2009 at 03:43:32PM +0200, Avi Kivity wrote: > On 12/22/2009 03:35 PM, Nikola Ciprich wrote: > >sorry to bring bad news, but it still doesn't compile (at least for me): > > > >[r...@vmdev03 qemu-kvm-0.12.1.1]# make > > LINK x86_64-softmmu/qemu-system-x86_64 > >machine.o: In function `cpu_pre_save': > >/usr/src/redhat/BUILD/qemu-kvm-0.12.1.1/target-i386/machine.c:326: undefined > >reference to `kvm_save_mpstate' > >collect2: ld returned 1 exit status > >make[1]: *** [qemu-system-x86_64] Error 1 > >make: *** [subdir-x86_64-softmmu] Error 2 > > Please provide details about your host. > > -- > 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 > -- - Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - -- 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] qemu-kvm-0.12.1.1
On 12/22/2009 04:07 PM, Nikola Ciprich wrote: CentOS5, all packages updated. But I just noticed build fails only when configured with multiple targets, including some more exotic (based on fedora spec). building just using x86_64-softmmu works fine for me. Okay, so at least it works out of the box (no special configure option). Hopefully someone will figure out why other targets cause it to fail - looks like some files are compiled with the wrong config.h. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Qemu vs Qemu-KVM
On Tue, Dec 22, 2009 at 09:15:57AM +0200, Gleb Natapov wrote: > On Mon, Dec 21, 2009 at 10:21:14PM +, Mikolaj Kucharski wrote: > > On Mon, Dec 21, 2009 at 09:22:52AM +0200, Gleb Natapov wrote: > > > > I have personal interest in resolving RedHat's bz #508801, unfortunately > > > > I cannot do that myself, so I wanted to ask on the list for help, but > > > > now > > > > I'm confused where should I go. > > > > > > > Can you try kvm modules from latest kvm.git please? It looks like > > > emulation of > > > "push %ds" fails and it was added after 2.6.32. > > > > Having following GIT repositories: > > > > git://git.kernel.org/pub/scm/virt/kvm/kvm.git > > git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git > > > > Which one I should use to build my modules from? I would like to keep my > > system (Fedora 12) consistent and I don't want to have any parts built > > outside of rpm. I would like to contribute/help for RedHat's bz #508801 > > resolution, but I need some directions. > > > > Is kvm.git whole Linux kernel? > > > Don't bother, I already tested upstream with OpenBSD and, as Avi said, > the problem is somewhere else. > For some strange reason openbsd configures gsi 4 (com0) and gsi 12 (i8042) to be level triggered active high in ioapic. That causes KVM to send endless stream of interrupts into the guest, so guest's stack overflows into framebuffer area. At this point KVM start to emulate instructions and fails. I don't know why openbsd configures those interrupts incorrectly. It also ignores my attempts to override interrupt polarity/type with ACPI tables. Somebody knowledgeable in openbsd should look into why it configures interrupt controller incorrectly. If I override wrong settings inside KVM like in the patch below openbsd boots, but I doubt com port is usable. diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c index 38a2d20..fc37eac 100644 --- a/virt/kvm/ioapic.c +++ b/virt/kvm/ioapic.c @@ -121,6 +121,8 @@ static void ioapic_write_indirect(struct kvm_ioapic *ioapic, u32 val) default: index = (ioapic->ioregsel - 0x10) >> 1; + if (!(ioapic->ioregsel & 1)) + val &= ~0xa000; ioapic_debug("change redir index %x val %x\n", index, val); if (index >= IOAPIC_NUM_PINS) return; -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] slow_map: minor improvements to ROM BAR handling
On Tue, Dec 22, 2009 at 02:34:42PM +0100, Alexander Graf wrote: > Michael S. Tsirkin wrote: > > On Tue, Dec 22, 2009 at 01:05:23PM +0100, Alexander Graf wrote: > > > >> Michael S. Tsirkin wrote: > >> > >>> ROM BAR can be handled same as regular BAR: > >>> load_option_roms utility will take care of > >>> copying it to RAM as appropriate. > >>> > >>> Signed-off-by: Michael S. Tsirkin > >>> --- > >>> > >>> This patch applies on top of agraf's one, > >>> it takes care of non-page aligned ROM BARs as well: > >>> they mostly are taken care of, we just do not > >>> need to warn user about them. > >>> > >>> hw/device-assignment.c | 20 +--- > >>> 1 files changed, 9 insertions(+), 11 deletions(-) > >>> > >>> diff --git a/hw/device-assignment.c b/hw/device-assignment.c > >>> index 000fa61..066fdb6 100644 > >>> --- a/hw/device-assignment.c > >>> +++ b/hw/device-assignment.c > >>> @@ -486,25 +486,23 @@ static int assigned_dev_register_regions(PCIRegion > >>> *io_regions, > >>> : PCI_BASE_ADDRESS_SPACE_MEMORY; > >>> > >>> if (cur_region->size & 0xFFF) { > >>> -fprintf(stderr, "PCI region %d at address 0x%llx " > >>> -"has size 0x%x, which is not a multiple of 4K. " > >>> -"You might experience some performance hit due > >>> to that.\n", > >>> -i, (unsigned long long)cur_region->base_addr, > >>> -cur_region->size); > >>> +if (i != PCI_ROM_SLOT) { > >>> +fprintf(stderr, "PCI region %d at address 0x%llx " > >>> +"has size 0x%x, which is not a multiple of > >>> 4K. " > >>> +"You might experience some performance hit " > >>> +"due to that.\n", > >>> +i, (unsigned long long)cur_region->base_addr, > >>> +cur_region->size); > >>> +} > >>> slow_map = 1; > >>> > >>> > >> This is wrong. You're setting slow_map = 1 on code that is very likely > >> to be executed inside the guest. That doesn't work. > >> > > > > It is? Can you really run code directly from a PCI card? > > I looked at BIOS boot specification and it always talks > > about shadowing PCI ROMs. > > > > I'm not sure the BIOS is the only one executing ROMs. If it is, then I'm > good with the change. > Maybe it'd make sense to also add a read only flag so we don't > accidently try to write to the ROM region with slow_map. > > Alex Correct: I think it's made readonly down the road with mprotect, so attempt to do so will crash qemu :) -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] slow_map: minor improvements to ROM BAR handling
On 12/22/2009 05:19 PM, Michael S. Tsirkin wrote: I'm not sure the BIOS is the only one executing ROMs. If it is, then I'm good with the change. Maybe it'd make sense to also add a read only flag so we don't accidently try to write to the ROM region with slow_map. Alex Correct: I think it's made readonly down the road with mprotect, so attempt to do so will crash qemu :) Alex, are you happy with this? I'd like to apply it. -- 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] slow_map: minor improvements to ROM BAR handling
Avi Kivity wrote: > On 12/22/2009 05:19 PM, Michael S. Tsirkin wrote: >> >>> I'm not sure the BIOS is the only one executing ROMs. If it is, then >>> I'm >>> good with the change. >>> Maybe it'd make sense to also add a read only flag so we don't >>> accidently try to write to the ROM region with slow_map. >>> >>> Alex >>> >> Correct: I think it's made readonly down the road with mprotect, >> so attempt to do so will crash qemu :) >> > > Alex, are you happy with this? I'd like to apply it. I'd like to see the read-only protection in. Apart from that I'm good on checking it in, though I'm only awaiting the day someone runs code off such a ROM region ;-). Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] slow_map: minor improvements to ROM BAR handling
On Tue, Dec 22, 2009 at 04:24:43PM +0100, Alexander Graf wrote: > Avi Kivity wrote: > > On 12/22/2009 05:19 PM, Michael S. Tsirkin wrote: > >> > >>> I'm not sure the BIOS is the only one executing ROMs. If it is, then > >>> I'm > >>> good with the change. > >>> Maybe it'd make sense to also add a read only flag so we don't > >>> accidently try to write to the ROM region with slow_map. > >>> > >>> Alex > >>> > >> Correct: I think it's made readonly down the road with mprotect, > >> so attempt to do so will crash qemu :) > >> > > > > Alex, are you happy with this? I'd like to apply it. > > I'd like to see the read-only protection in. Yes, this is a must, I am working on it. > Apart from that I'm good on checking it in, though I'm only awaiting > the day someone runs code off such a ROM region ;-). > > Alex Is there a way to trap this and fprintf something? -- 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: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 05:49 AM, Andi Kleen wrote: Anthony Liguori writes: On a modern Nehalem, I would be surprised if an MMIO exit handled in the kernel was muck more than 2us. The hardware is getting very, very fast. The trends here are very important to consider when we're looking at architectures that we potentially are going to support for a long time. When you talk about trends the trend for IO is also to get faster. An exit will be always more expensive than passing something from another CPU in shared memory. An exit is much more work, with lots of saved context and fundamentally synchronous, even with all the tricks hardware can do. And then there's the in kernel handler too. Noone is advocating avoiding shared memory and doing more exits in the IO path :-) Whether it's x2apic support or whether it's more sophisicated hardware apic virtualization support, the point remains that taking an exit due to EOI is likely to not be required in the near term future. So far, the only actual technical advantage I've seen is that vbus avoids EOI exits. My response is that I don't think that that's so important especially when you consider that it's going to not matter so much in the future and that Avi has some ideas about how to eliminate some of them even on older hardware. I'm also suspicious that EOI exits alone would result in a huge performance differiental between the two architectures. We think we understand why vbus does better than the current userspace virtio backend. That's why we're building vhost-net. It's not done yet, but our expectation is that it will do just as well if not better. Shared memory passing from another CPU is a much cheaper operation and more likely to scale with IO rate improvements. The basic problem in this discussion seems to be the usual disconnect between working code (I understand Gregory has working code that demonstrates the performance advances he's claiming) versus unwritten optimizations. vbus has one driver (networking) that supports one guest (very new Linux kernels). It supports one hypervisor (KVM) on one architecture (x86). On the other hand, virtio has six upstream drivers (console, network, block, rng, balloon, 9p) with at least as many in development. It supports kernels going back to at least 2.6.18, almost all versions of Windows, and has experimental drivers for other OSes. It supports KVM, lguest, VirtualBox, with support for additional hypervisors under development. It supports at least five architectures (x86, ppc, s390, ia64, arm). You are correct, vbus has better numbers than virtio today. But so far, it's hardly an apples-to-apples comparison. Our backend networking driver has been implemented entirely in userspace up until very recently. There really isn't any good performance data comparing vbus to vhost-net largely because vhost-net is still under active development. The most important point though, is that so far, I don't think Greg has been able to articulate _why_ vbus would perform better than vhost-net. If that can be articulated in a way that we all agree vbus has a technical advantage over vhost-net, then I'm absolutely in agreement that it should be merged. I think the comparison would be if someone submitted a second e1000 driver that happened to do better on one netperf test than the current e1000 driver. You can argue, hey, choice is good, let's let a user choose if they want to use the faster e1000 driver. But surely, the best thing for a user is to figure out why the second e1000 driver is better on that one test, integrate that change into the current e1000 driver, or decided that the new e1000 driver is more superior in architecture and do the required work to make the new e1000 driver a full replacement for the old one. Regards, Anthony Liguori Unwritten code tends to always sound nicer, but it remains to be seen if it can deliver what it promises. From a abstract stand point having efficient paravirtual IO interfaces seem attractive. I also personally don't see a big problem in having another set of virtual drivers -- Linux already has plenty (vmware, xen, virtio, power, s390-vm, ...) and it's not that they would be a particular maintenance burden impacting the kernel core. -Andi -- 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] slow_map: minor improvements to ROM BAR handling
Michael S. Tsirkin wrote: > On Tue, Dec 22, 2009 at 04:24:43PM +0100, Alexander Graf wrote: > >> Avi Kivity wrote: >> >>> On 12/22/2009 05:19 PM, Michael S. Tsirkin wrote: >>> > I'm not sure the BIOS is the only one executing ROMs. If it is, then > I'm > good with the change. > Maybe it'd make sense to also add a read only flag so we don't > accidently try to write to the ROM region with slow_map. > > Alex > > Correct: I think it's made readonly down the road with mprotect, so attempt to do so will crash qemu :) >>> Alex, are you happy with this? I'd like to apply it. >>> >> I'd like to see the read-only protection in. >> > > Yes, this is a must, I am working on it. > > >> Apart from that I'm good on checking it in, though I'm only awaiting >> the day someone runs code off such a ROM region ;-). >> >> Alex >> > > Is there a way to trap this and fprintf something? I don't think so. KVM will just trap on execution outside of RAM and either fail badly or throw something bad into the guest. MMIO access works by analyzing the instruction that accesses the MMIO address. That just doesn't work when we don't have an instruction to analyze. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] slow_map: minor improvements to ROM BAR handling
On 12/22/2009 05:36 PM, Alexander Graf wrote: Is there a way to trap this and fprintf something? I don't think so. KVM will just trap on execution outside of RAM and either fail badly or throw something bad into the guest. MMIO access works by analyzing the instruction that accesses the MMIO address. That just doesn't work when we don't have an instruction to analyze. We could certainly extend emulate.c to fetch instruction bytes from userspace. It uses ->read_std() now, so we'd need to switch to ->read_emulated() and add appropriate buffering. -- 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] slow_map: minor improvements to ROM BAR handling
Avi Kivity wrote: > On 12/22/2009 05:36 PM, Alexander Graf wrote: >> >>> Is there a way to trap this and fprintf something? >>> >> I don't think so. KVM will just trap on execution outside of RAM and >> either fail badly or throw something bad into the guest. MMIO access >> works by analyzing the instruction that accesses the MMIO address. That >> just doesn't work when we don't have an instruction to analyze. >> > > We could certainly extend emulate.c to fetch instruction bytes from > userspace. It uses ->read_std() now, so we'd need to switch to > ->read_emulated() and add appropriate buffering. I thought the policy on emulate.c was to not have a full instruction emulator but only emulate instructions that do PT modifications or MMIO access? Btw, we're in the same situation with PowerPC here. The instruction emulator is _really_ small. It only does a few MMU specific instructions, a couple of privileged ones and MMIO accessing ones. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] slow_map: minor improvements to ROM BAR handling
On 12/22/2009 05:41 PM, Alexander Graf wrote: We could certainly extend emulate.c to fetch instruction bytes from userspace. It uses ->read_std() now, so we'd need to switch to ->read_emulated() and add appropriate buffering. I thought the policy on emulate.c was to not have a full instruction emulator but only emulate instructions that do PT modifications or MMIO access? It's not a policy, just laziness. With emulate_invalid_guest_state=1 we need many more instructions. Of course I don't want to add instructions just for the sake of it, since they will be untested. I'd much prefer not to run from mmio if possible - just pointing out it's doable. Btw, we're in the same situation with PowerPC here. The instruction emulator is _really_ small. It only does a few MMU specific instructions, a couple of privileged ones and MMIO accessing ones. Plus, you have a fixed length instruction length, likely more regular too. I imagine powerpc is load/store, so you don't have to emulate a zillion ALU instructions? -- 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] slow_map: minor improvements to ROM BAR handling
Avi Kivity wrote: > On 12/22/2009 05:41 PM, Alexander Graf wrote: >> >>> We could certainly extend emulate.c to fetch instruction bytes from >>> userspace. It uses ->read_std() now, so we'd need to switch to >>> ->read_emulated() and add appropriate buffering. >>> >> I thought the policy on emulate.c was to not have a full instruction >> emulator but only emulate instructions that do PT modifications or MMIO >> access? >> > > It's not a policy, just laziness. With emulate_invalid_guest_state=1 > we need many more instructions. Of course I don't want to add > instructions just for the sake of it, since they will be untested. > > I'd much prefer not to run from mmio if possible - just pointing out > it's doable. Right... >> emulator is _really_ small. It only does a few MMU specific >> instructions, a couple of privileged ones and MMIO accessing ones. >> > Btw, we're in the same situation with PowerPC here. The instruction > > Plus, you have a fixed length instruction length, likely more regular > too. I imagine powerpc is load/store, so you don't have to emulate a > zillion ALU instructions? Well, it's certainly doable (and easier than on x86). But I'm on the same position as you on the x86 side. Why increase the emulator size at least 10 times if we don't have to? Either way, people will report bugs when / if they actually start executing code off MMIO. So let's not care too much about it for now. Just make sure the read-only check is in. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On Tuesday 22 December 2009 04:31:32 pm Anthony Liguori wrote: > I think the comparison would be if someone submitted a second e1000 > driver that happened to do better on one netperf test than the current > e1000 driver. > > You can argue, hey, choice is good, let's let a user choose if they want > to use the faster e1000 driver. But surely, the best thing for a user > is to figure out why the second e1000 driver is better on that one test, > integrate that change into the current e1000 driver, or decided that the Even though this is "Won't somebody please think of the users?" argument such work would be much welcomed. Sending patches would be a great start.. > new e1000 driver is more superior in architecture and do the required > work to make the new e1000 driver a full replacement for the old one. Right, like everyone actually does things this way.. I wonder why do we have OSS, old Firewire and IDE stacks still around then? > Regards, > > Anthony Liguori > > > Unwritten code tends to always sound nicer, but it remains to be seen > > if it can deliver what it promises. > > > > From a abstract stand point having efficient paravirtual IO interfaces > > seem attractive. > > > > I also personally don't see a big problem in having another set of > > virtual drivers -- Linux already has plenty (vmware, xen, virtio, power, > > s390-vm, ...) and it's not that they would be a particular maintenance > > burden impacting the kernel core. Exactly, I also don't see any problem here, especially since AlacrityVM drivers have much cleaner design / internal architecture than some of their competitors.. -- Bartlomiej Zolnierkiewicz -- 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] slow_map: minor improvements to ROM BAR handling
On Tue, Dec 22, 2009 at 05:00:52PM +0100, Alexander Graf wrote: > Avi Kivity wrote: > > On 12/22/2009 05:41 PM, Alexander Graf wrote: > >> > >>> We could certainly extend emulate.c to fetch instruction bytes from > >>> userspace. It uses ->read_std() now, so we'd need to switch to > >>> ->read_emulated() and add appropriate buffering. > >>> > >> I thought the policy on emulate.c was to not have a full instruction > >> emulator but only emulate instructions that do PT modifications or MMIO > >> access? > >> > > > > It's not a policy, just laziness. With emulate_invalid_guest_state=1 > > we need many more instructions. Of course I don't want to add > > instructions just for the sake of it, since they will be untested. > > > > I'd much prefer not to run from mmio if possible - just pointing out > > it's doable. > > Right... > > >> emulator is _really_ small. It only does a few MMU specific > >> instructions, a couple of privileged ones and MMIO accessing ones. > >> > > Btw, we're in the same situation with PowerPC here. The instruction > > > > Plus, you have a fixed length instruction length, likely more regular > > too. I imagine powerpc is load/store, so you don't have to emulate a > > zillion ALU instructions? > > Well, it's certainly doable (and easier than on x86). But I'm on the > same position as you on the x86 side. Why increase the emulator size at > least 10 times if we don't have to? > > Either way, people will report bugs when / if they actually start > executing code off MMIO. So let's not care too much about it for now. > Just make sure the read-only check is in. > > Alex So I think all we need is this on top? diff --git a/hw/device-assignment.c b/hw/device-assignment.c index 066fdb6..0c3c8f4 100644 --- a/hw/device-assignment.c +++ b/hw/device-assignment.c @@ -233,7 +233,8 @@ static void assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num, int m; DEBUG("slow map\n"); -m = cpu_register_io_memory(slow_bar_read, slow_bar_write, region); +m = cpu_register_io_memory(slow_bar_read, region_num == PCI_ROM_SLOT ? + NULL : slow_bar_write, region); cpu_register_physical_memory(e_phys, e_size, m); /* MSI-X MMIO page */ -- 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] slow_map: minor improvements to ROM BAR handling
Michael S. Tsirkin wrote: > On Tue, Dec 22, 2009 at 05:00:52PM +0100, Alexander Graf wrote: > >> Avi Kivity wrote: >> >>> On 12/22/2009 05:41 PM, Alexander Graf wrote: >>> > We could certainly extend emulate.c to fetch instruction bytes from > userspace. It uses ->read_std() now, so we'd need to switch to > ->read_emulated() and add appropriate buffering. > > I thought the policy on emulate.c was to not have a full instruction emulator but only emulate instructions that do PT modifications or MMIO access? >>> It's not a policy, just laziness. With emulate_invalid_guest_state=1 >>> we need many more instructions. Of course I don't want to add >>> instructions just for the sake of it, since they will be untested. >>> >>> I'd much prefer not to run from mmio if possible - just pointing out >>> it's doable. >>> >> Right... >> >> emulator is _really_ small. It only does a few MMU specific instructions, a couple of privileged ones and MMIO accessing ones. >>> Btw, we're in the same situation with PowerPC here. The instruction >>> >>> Plus, you have a fixed length instruction length, likely more regular >>> too. I imagine powerpc is load/store, so you don't have to emulate a >>> zillion ALU instructions? >>> >> Well, it's certainly doable (and easier than on x86). But I'm on the >> same position as you on the x86 side. Why increase the emulator size at >> least 10 times if we don't have to? >> >> Either way, people will report bugs when / if they actually start >> executing code off MMIO. So let's not care too much about it for now. >> Just make sure the read-only check is in. >> >> Alex >> > > So I think all we need is this on top? > > diff --git a/hw/device-assignment.c b/hw/device-assignment.c > index 066fdb6..0c3c8f4 100644 > --- a/hw/device-assignment.c > +++ b/hw/device-assignment.c > @@ -233,7 +233,8 @@ static void assigned_dev_iomem_map_slow(PCIDevice > *pci_dev, int region_num, > int m; > > DEBUG("slow map\n"); > -m = cpu_register_io_memory(slow_bar_read, slow_bar_write, region); > +m = cpu_register_io_memory(slow_bar_read, region_num == PCI_ROM_SLOT ? > + NULL : slow_bar_write, region); > cpu_register_physical_memory(e_phys, e_size, m); > > /* MSI-X MMIO page */ > I guess so, yes. I'd prefer a written out if statement though, but that's probably personal preference. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
> So far, the only actual technical advantage I've seen is that vbus avoids > EOI exits. The technical advantage is that it's significantly faster today. Maybe your proposed alternative is as fast, or maybe it's not. Who knows? > We think we understand why vbus does better than the current userspace > virtio backend. That's why we're building vhost-net. It's not done yet, > but our expectation is that it will do just as well if not better. That's the vapourware vs working code disconnect I mentioned. One side has hard numbers&working code and the other has expectations. I usually find it sad when the vapourware holds up the working code. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 10:01 AM, Bartlomiej Zolnierkiewicz wrote: new e1000 driver is more superior in architecture and do the required work to make the new e1000 driver a full replacement for the old one. Right, like everyone actually does things this way.. I wonder why do we have OSS, old Firewire and IDE stacks still around then? And it's always a source of pain, isn't it. I also personally don't see a big problem in having another set of virtual drivers -- Linux already has plenty (vmware, xen, virtio, power, s390-vm, ...) and it's not that they would be a particular maintenance burden impacting the kernel core. Exactly, I also don't see any problem here, especially since AlacrityVM drivers have much cleaner design / internal architecture than some of their competitors.. Care to provide some actual objective argument to why it's better than what we already have? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 10:21 AM, Andi Kleen wrote: So far, the only actual technical advantage I've seen is that vbus avoids EOI exits. The technical advantage is that it's significantly faster today. There are two separate pieces of code in question. There are front-end drivers and there are back-end drivers. Right now, there are only front-end drivers in the kernel today. The combination of vbus front-end drivers and *kernel* back-end drivers are faster than the *combination* of virtio front-end drivers and *userspace* back-end drivers. vhost-net is our kernel back-end driver. No one has yet established that the combination of virtio front-end driver and kernel back-end driver is really significantly slower than vbus. Maybe your proposed alternative is as fast, or maybe it's not. Who knows? We think we understand why vbus does better than the current userspace virtio backend. That's why we're building vhost-net. It's not done yet, but our expectation is that it will do just as well if not better. That's the vapourware vs working code disconnect I mentioned. One side has hard numbers&working code and the other has expectations. I usually find it sad when the vapourware holds up the working code. We're not talking about vaporware. vhost-net exists. Regards, Anthony Liguori -Andi -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 06:21 PM, Andi Kleen wrote: So far, the only actual technical advantage I've seen is that vbus avoids EOI exits. The technical advantage is that it's significantly faster today. Maybe your proposed alternative is as fast, or maybe it's not. Who knows? We're working on numbers for the proposed alternative, so we should know soon. Are the AlacrityVM folks working on having all the virtio drivers for all the virtio archs? We shouldn't drop everything and switch to new code just because someone came up with a new idea. The default should be to enhance the existing code. We think we understand why vbus does better than the current userspace virtio backend. That's why we're building vhost-net. It's not done yet, but our expectation is that it will do just as well if not better. That's the vapourware vs working code disconnect I mentioned. One side has hard numbers&working code and the other has expectations. I usually find it sad when the vapourware holds up the working code. vhost-net is working code and is queued for 2.6.33. -- 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 0/6 v2] Add support for RDTSCP in VMX
On Sun, Dec 20, 2009 at 11:30:00AM +0200, Avi Kivity wrote: > On 12/18/2009 10:48 AM, Sheng Yang wrote: > > Applied all, thanks. Need to save/restore MSR_TSC_AUX in qemu-kvm. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
> We're not talking about vaporware. vhost-net exists. Is it as fast as the alacrityvm setup then e.g. for network traffic? Last I heard the first could do wirespeed 10Gbit/s on standard hardware. Can vhost-net do the same thing? -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 07:33 PM, Andi Kleen wrote: We're not talking about vaporware. vhost-net exists. Is it as fast as the alacrityvm setup then e.g. for network traffic? Last I heard the first could do wirespeed 10Gbit/s on standard hardware. That was with zero-copy IIRC, which is known broken. There's nothing alacrity-specific about zerocopy (and in fact the first zerocopy patches were from Rusty). Can vhost-net do the same thing? I've heard unofficial numbers which approach that, but let's wait for the official ones. -- 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: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 2:57 AM, Ingo Molnar wrote: > > * Gregory Haskins wrote: > >> On 12/18/09 4:51 PM, Ingo Molnar wrote: >>> >>> * Gregory Haskins wrote: >>> Hi Linus, Please pull AlacrityVM guest support for 2.6.33 from: git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git for-linus All of these patches have stewed in linux-next for quite a while now: Gregory Haskins (26): >>> >>> I think it would be fair to point out that these patches have been objected >>> to >>> by the KVM folks quite extensively, >> >> Actually, these patches have nothing to do with the KVM folks. [...] > > That claim is curious to me - the AlacrityVM host It's quite simple, really. These drivers support accessing vbus, and vbus is hypervisor agnostic. In fact, vbus isn't necessarily even hypervisor related. It may be used anywhere where a Linux kernel is the "io backend", which includes hypervisors like AlacrityVM, but also userspace apps, and interconnected physical systems as well. The vbus-core on the backend, and the drivers on the frontend operate completely independent of the underlying hypervisor. A glue piece called a "connector" ties them together, and any "hypervisor" specific details are encapsulated in the connector module. In this case, the connector surfaces to the guest side as a pci-bridge, so even that is not hypervisor specific per se. It will work with any pci-bridge that exposes a compatible ABI, which conceivably could be actual hardware. The AlacrityVM project just so happens to be the primary consumer, and is therefore the most convenient way to package them up at the moment. > is 90% based on KVM code, so > how can it not be about KVM? I just checked, most of the changes that > AlacrityVM host does to KVM is in adding the host side interfaces for these > guest drivers: > > virt/kvm/Kconfig | 11 + > virt/kvm/coalesced_mmio.c | 65 +++--- > virt/kvm/coalesced_mmio.h |1 + > virt/kvm/eventfd.c| 599 > + > virt/kvm/ioapic.c | 118 +++-- > virt/kvm/ioapic.h |5 + > virt/kvm/iodev.h | 55 +++-- > virt/kvm/irq_comm.c | 267 ++--- > virt/kvm/kvm_main.c | 127 -- > virt/kvm/xinterface.c | 587 > 10 files changed, 1649 insertions(+), 186 deletions(-) > > [ stat for virt/kvm/ taken as of today, AlacrityVM host tree commit 84afcc7 ] > > So as far as kernel code modifications of AlacrityVM goes, it's very much > about KVM. I think you are confused. Even if we entertained the notion that the host side diffstat were somehow relevant here, you are probably comparing the kvm.git backports that are in my tree. The only real KVM specific change that is in my tree is the 587 lines for the xinterface.c module, which is about ~4%, not 90%. Also note that I have pushed this xinterface logic upstream already, but it just hasn't been accepted yet. If I wanted to be extremely generous, you could include the entire "KVM connector" code that bridges vbus-core to kvm-core, but even that tops out at a total of ~17% of the changes in my tree. So I am still not seeing the 90% nor how it is relevant. > >> [...] You are perhaps confusing this with the hypervisor-side discussion, >> of which there is indeed much disagreement. > > Are the guest drivers living in a vacuum? The whole purpose of the AlacrityVM > guest drivers is to ... enable AlacrityVM support, right? More specifically, the purpose of the drivers, like any driver, is to enable support for the underlying device in which it is related to. In this case, the devices are vbus based devices. Of those, AlacrityVM is the only available platform that exposes them. However, that is a maturity/adoption detail, not a technical limitation. Simply implementing a new connector would bridge these drivers to other environments as well. There are community members working on these as we speak, as a matter of fact. > So how can it be not about KVM? Because AlacrityVM is a hypervisor that supports VBUS for PV IO, and KVM is not. In addition, the presence of these drivers in no way alters, interferes with, or diminishes features found in KVM today. So it is, and never will be about KVM until upstream KVM decides that they want to support VBUS based PV-IO. If you want to talk about the host side, then I have +587 lines that hang in the balance that affect KVM, yes. But that isn't what $subject was about. > > Gregory, it would be nice if you worked _much_ harder with the KVM folks > before giving up. I think the 5+ months that I politely tried to convince the KVM folks that this was a good idea was pretty generous of my employer. The KVM maintainers have ultimately made it clear they are not interested in directly supporting this concept (which is their prerogative), but are perhaps will
[PATCH] vhost-net: comment use of invalid fd when setting vhost backend
This looks like an error case, but it's just a special case to shutdown the backend. Clarify with a comment. Signed-off-by: Chris Wright --- drivers/vhost/net.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 22d5fef..cc92086 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -465,6 +465,7 @@ static struct socket *get_tun_socket(int fd) static struct socket *get_socket(int fd) { struct socket *sock; + /* special case to disable backend */ if (fd == -1) return NULL; sock = get_raw_socket(fd); -- 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/6 v2] Add support for RDTSCP in VMX
On 12/22/2009 07:26 PM, Marcelo Tosatti wrote: On Sun, Dec 20, 2009 at 11:30:00AM +0200, Avi Kivity wrote: On 12/18/2009 10:48 AM, Sheng Yang wrote: Applied all, thanks. Need to save/restore MSR_TSC_AUX in qemu-kvm. Should be automatic. After all, we expose all the MSR list, so qemu can read it and save everything there. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 07:36 PM, Gregory Haskins wrote: Gregory, it would be nice if you worked _much_ harder with the KVM folks before giving up. I think the 5+ months that I politely tried to convince the KVM folks that this was a good idea was pretty generous of my employer. The KVM maintainers have ultimately made it clear they are not interested in directly supporting this concept (which is their prerogative), but are perhaps willing to support the peripheral logic needed to allow it to easily interface with KVM. I can accept that, and thus AlacrityVM was born. Review pointed out locking issues with xinterface which I have not seen addressed. I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did not reply. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 1:53 PM, Avi Kivity wrote: > On 12/22/2009 07:36 PM, Gregory Haskins wrote: >> >>> Gregory, it would be nice if you worked _much_ harder with the KVM folks >>> before giving up. >>> >> I think the 5+ months that I politely tried to convince the KVM folks >> that this was a good idea was pretty generous of my employer. The KVM >> maintainers have ultimately made it clear they are not interested in >> directly supporting this concept (which is their prerogative), but are >> perhaps willing to support the peripheral logic needed to allow it to >> easily interface with KVM. I can accept that, and thus AlacrityVM was >> born. >> > > Review pointed out locking issues with xinterface which I have not seen > addressed. I asked why the irqfd/ioeventfd mechanisms are insufficient, > and you did not reply. > Yes, I understand. I've been too busy to rework the code for an upstream push. I will certainly address those questions when I make the next attempt, but they weren't relevant to the guest side. signature.asc Description: OpenPGP digital signature
[PATCH] vhost-net: defer f->private_data until setup succeeds
Trivial change, just for readability. The filp is not installed on failure, so the current code is not incorrect (also vhost_dev_init currently has no failure case). This just treats setting f->private_data as something with global scope (sure, true only after fd_install). Signed-off-by: Chris Wright --- drivers/vhost/net.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 22d5fef..0697ab2 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -326,7 +326,6 @@ static int vhost_net_open(struct inode *inode, struct file *f) int r; if (!n) return -ENOMEM; - f->private_data = n; n->vqs[VHOST_NET_VQ_TX].handle_kick = handle_tx_kick; n->vqs[VHOST_NET_VQ_RX].handle_kick = handle_rx_kick; r = vhost_dev_init(&n->dev, n->vqs, VHOST_NET_VQ_MAX); @@ -338,6 +337,9 @@ static int vhost_net_open(struct inode *inode, struct file *f) vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, POLLOUT); vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, POLLIN); n->tx_poll_state = VHOST_NET_POLL_DISABLED; + + f->private_data = n; + return 0; } -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 1:53 PM, Avi Kivity wrote: > I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did not > reply. > BTW: the ioeventfd issue just fell through the cracks, so sorry about that. Note that I have no specific issue with irqfd ever since the lockless IRQ injection code was added. ioeventfd turned out to be suboptimal for me in the fast path for two reasons: 1) the underlying eventfd is called in atomic context. I had posted patches to Davide to address that limitation, but I believe he rejected them on the grounds that they are only relevant to KVM. 2) it cannot retain the data field passed in the PIO. I wanted to have one vector that could tell me what value was written, and this cannot be expressed in ioeventfd. Based on this, it was a better decision to add a ioevent interface to xinterface. It neatly solves both problems. Kind Regards, -Greg signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 09:15 PM, Gregory Haskins wrote: On 12/22/09 1:53 PM, Avi Kivity wrote: I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did not reply. BTW: the ioeventfd issue just fell through the cracks, so sorry about that. Note that I have no specific issue with irqfd ever since the lockless IRQ injection code was added. ioeventfd turned out to be suboptimal for me in the fast path for two reasons: 1) the underlying eventfd is called in atomic context. I had posted patches to Davide to address that limitation, but I believe he rejected them on the grounds that they are only relevant to KVM. If you're not doing something pretty minor, you're better of waking up a thread (perhaps _sync if you want to keep on the same cpu). With the new user return notifier thingie, that's pretty cheap. 2) it cannot retain the data field passed in the PIO. I wanted to have one vector that could tell me what value was written, and this cannot be expressed in ioeventfd. It would be easier to add data logging support to ioeventfd, if it was needed that badly. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 2:25 PM, Avi Kivity wrote: > On 12/22/2009 09:15 PM, Gregory Haskins wrote: >> On 12/22/09 1:53 PM, Avi Kivity wrote: >> >>> I asked why the irqfd/ioeventfd mechanisms are insufficient, and you >>> did not reply. >>> >>> >> BTW: the ioeventfd issue just fell through the cracks, so sorry about >> that. Note that I have no specific issue with irqfd ever since the >> lockless IRQ injection code was added. >> >> ioeventfd turned out to be suboptimal for me in the fast path for two >> reasons: >> >> 1) the underlying eventfd is called in atomic context. I had posted >> patches to Davide to address that limitation, but I believe he rejected >> them on the grounds that they are only relevant to KVM. >> > > If you're not doing something pretty minor, you're better of waking up a > thread (perhaps _sync if you want to keep on the same cpu). With the > new user return notifier thingie, that's pretty cheap. We have exploits that take advantage of IO heuristics. When triggered they do more work in vcpu context than normal, which reduces latency under certain circumstances. But you definitely do _not_ want to do them in-atomic ;) > >> 2) it cannot retain the data field passed in the PIO. I wanted to have >> one vector that could tell me what value was written, and this cannot be >> expressed in ioeventfd. >> >> > > It would be easier to add data logging support to ioeventfd, if it was > needed that badly. "Better design"? perhaps. "More easily"? no. Besides, Davide has already expressed dissatisfaction with the KVM-isms creeping into eventfd, so its not likely to ever be accepted regardless of your own disposition. xinterface, as it turns out, is a great KVM interface for me and easy to extend, all without conflicting with the changes in upstream. The old way was via the kvm ioctl interface, but that sucked as the ABI was always moving. Where is the problem? ioeventfd still works fine as it is. Kind Regards, -Greg signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 2:32 PM, Gregory Haskins wrote: > On 12/22/09 2:25 PM, Avi Kivity wrote: >> >> If you're not doing something pretty minor, you're better of waking up a >> thread (perhaps _sync if you want to keep on the same cpu). With the >> new user return notifier thingie, that's pretty cheap. > > We have exploits that take advantage of IO heuristics. When triggered > they do more work in vcpu context than normal, which reduces latency > under certain circumstances. But you definitely do _not_ want to do > them in-atomic ;) And I almost forgot: dev->call() is an RPC to the backend device. Therefore, it must be synchronous, yet we dont want it locked either. I think that was actually the primary motivation for the change, now that I think about it. -Greg signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 09:32 PM, Gregory Haskins wrote: xinterface, as it turns out, is a great KVM interface for me and easy to extend, all without conflicting with the changes in upstream. The old way was via the kvm ioctl interface, but that sucked as the ABI was always moving. Where is the problem? ioeventfd still works fine as it is. It means that kvm locking suddenly affects more of the kernel. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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] vhost-net: comment use of invalid fd when setting vhost backend
On Tue, Dec 22, 2009 at 10:18:28AM -0800, Chris Wright wrote: > This looks like an error case, but it's just a special case to shutdown > the backend. Clarify with a comment. > > Signed-off-by: Chris Wright Acked-by: Michael S. Tsirkin > --- > drivers/vhost/net.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 22d5fef..cc92086 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -465,6 +465,7 @@ static struct socket *get_tun_socket(int fd) > static struct socket *get_socket(int fd) > { > struct socket *sock; > + /* special case to disable backend */ > if (fd == -1) > return NULL; > sock = get_raw_socket(fd); -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 2:38 PM, Avi Kivity wrote: > On 12/22/2009 09:32 PM, Gregory Haskins wrote: >> xinterface, as it turns out, is a great KVM interface for me and easy to >> extend, all without conflicting with the changes in upstream. The old >> way was via the kvm ioctl interface, but that sucked as the ABI was >> always moving. Where is the problem? ioeventfd still works fine as >> it is. >> > > It means that kvm locking suddenly affects more of the kernel. > Thats ok. This would only be w.r.t. devices that are bound to the KVM instance anyway, so they better know what they are doing (and they do). -Greg signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 09:32 PM, Gregory Haskins wrote: Besides, Davide has already expressed dissatisfaction with the KVM-isms creeping into eventfd, so its not likely to ever be accepted regardless of your own disposition. Why don't you duplicate eventfd, then, should be easier than duplicating virtio. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 09:41 PM, Gregory Haskins wrote: It means that kvm locking suddenly affects more of the kernel. Thats ok. This would only be w.r.t. devices that are bound to the KVM instance anyway, so they better know what they are doing (and they do). It's okay to the author of that device. It's not okay to the kvm developers who are still evolving the locking and have to handle all devices that use xinterface. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 2:43 PM, Avi Kivity wrote: > On 12/22/2009 09:41 PM, Gregory Haskins wrote: >> >>> It means that kvm locking suddenly affects more of the kernel. >>> >>> >> Thats ok. This would only be w.r.t. devices that are bound to the KVM >> instance anyway, so they better know what they are doing (and they do). >> >> > > It's okay to the author of that device. It's not okay to the kvm > developers who are still evolving the locking and have to handle all > devices that use xinterface. Perhaps, but like it or not, if you want to do in-kernel you need to invoke backends. And if you want to invoke backends, limiting it to thread wakeups is, well, limiting. For one, you miss out on that exploit I mentioned earlier which can help sometimes. Besides, the direction that Marcelo and I left the mmio/pio bus was that it would go lockless eventually, not "more lockful" ;) Has that changed? I honestly haven't followed whats going on in the io-bus code in a while. -Greg signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On Tue, 22 Dec 2009, Gregory Haskins wrote: > On 12/22/09 1:53 PM, Avi Kivity wrote: > > I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did > > not reply. > > > > BTW: the ioeventfd issue just fell through the cracks, so sorry about > that. Note that I have no specific issue with irqfd ever since the > lockless IRQ injection code was added. > > ioeventfd turned out to be suboptimal for me in the fast path for two > reasons: > > 1) the underlying eventfd is called in atomic context. I had posted > patches to Davide to address that limitation, but I believe he rejected > them on the grounds that they are only relevant to KVM. I thought we addressed this already, in the few hundreds of email we exchanged back then :) > 2) it cannot retain the data field passed in the PIO. I wanted to have > one vector that could tell me what value was written, and this cannot be > expressed in ioeventfd. Like might have hinted in his reply, couldn't you add data support to the ioeventfd bits in KVM, instead of leaking them into mainline eventfd? - Davide -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 2:39 PM, Davide Libenzi wrote: > On Tue, 22 Dec 2009, Gregory Haskins wrote: > >> On 12/22/09 1:53 PM, Avi Kivity wrote: >>> I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did >>> not reply. >>> >> >> BTW: the ioeventfd issue just fell through the cracks, so sorry about >> that. Note that I have no specific issue with irqfd ever since the >> lockless IRQ injection code was added. >> >> ioeventfd turned out to be suboptimal for me in the fast path for two >> reasons: >> >> 1) the underlying eventfd is called in atomic context. I had posted >> patches to Davide to address that limitation, but I believe he rejected >> them on the grounds that they are only relevant to KVM. > > I thought we addressed this already, in the few hundreds of email we > exchanged back then :) We addressed the race conditions, but not the atomic callbacks. I can't remember exactly what you said, but the effect was "no", so I dropped it. ;) This was the thread. http://www.archivum.info/linux-ker...@vger.kernel.org/2009-06/08548/Re:_[KVM-RFC_PATCH_1_2]_eventfd:_add_an_explicit_srcu_based_notifier_interface > > > >> 2) it cannot retain the data field passed in the PIO. I wanted to have >> one vector that could tell me what value was written, and this cannot be >> expressed in ioeventfd. > > Like might have hinted in his reply, couldn't you add data support to the > ioeventfd bits in KVM, instead of leaking them into mainline eventfd? > Perhaps, or even easier I could extend xinterface. Which is what I did ;) The problem with the first proposal is that you would no longer actually have an eventfd based mechanism...so any code using ioeventfd (like Michael Tsirkin's for instance) would break. Kind Regards, -Greg signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/21/09 7:12 PM, Anthony Liguori wrote: > On 12/21/2009 11:44 AM, Gregory Haskins wrote: >> Well, surely something like SR-IOV is moving in that direction, no? >> > > Not really, but that's a different discussion. Ok, but my general point still stands. At some level, some crafty hardware engineer may invent something that obsoletes the need for, say, PV 802.x drivers because it can hit 40GE line rate at the same performance level of bare metal with some kind of pass-through trick. But I still do not see that as an excuse for sloppy software in the meantime, as there will always be older platforms, older IO cards, or different IO types that are not benefactors of said hw based optimizations. > >>> But let's focus on concrete data. For a given workload, >>> how many exits do you see due to EOI? >>> >> Its of course highly workload dependent, and I've published these >> details in the past, I believe. Off the top of my head, I recall that >> virtio-pci tends to throw about 65k exits per second, vs about 32k/s for >> venet on a 10GE box, but I don't recall what ratio of those exits are >> EOI. > > Was this userspace virtio-pci or was this vhost-net? Both, actually, though userspace is obviously even worse. > If it was the > former, then were you using MSI-X? MSI-X > If you weren't, there would be an > additional (rather heavy) exit per-interrupt to clear the ISR which > would certainly account for a large portion of the additional exits. > Yep, if you don't use MSI it is significantly worse as expected. >>To be perfectly honest, I don't care. I do not discriminate >> against the exit type...I want to eliminate as many as possible, >> regardless of the type. That's how you go fast and yet use less CPU. >> > > It's important to understand why one mechanism is better than another. Agreed, but note _I_ already understand why. I've certainly spent countless hours/emails trying to get others to understand as well, but it seems most are too busy to actually listen. > All I'm looking for is a set of bullet points that say, vbus does this, > vhost-net does that, therefore vbus is better. We would then either > say, oh, that's a good idea, let's change vhost-net to do that, or we > would say, hrm, well, we can't change vhost-net to do that because of > some fundamental flaw, let's drop it and adopt vbus. > > It's really that simple :-) This is all been covered ad-nauseam, directly with youself in many cases. Google is your friend. Here are some tips while you research: Do not fall into the trap of vhost-net vs vbus, or venet vs virtio-net, or you miss the point entirely. Recall that venet was originally crafted to demonstrate the virtues of my three performance objectives (kill exits, reduce exit overhead, and run concurrently). Then there is all the stuff we are laying on top, like qos, real-time, advanced fabrics, and easy adoption for various environments (so it doesn't need to be redefined each time). Therefore if you only look at the limited feature set of virtio-net, you will miss the majority of the points of the framework. virtio tried to capture some of these ideas, but it missed the mark on several levels and was only partially defined. Incidentally, you can stil run virtio over vbus if desired, but so far no one has tried to use my transport. > > >>> They should be relatively rare >>> because obtaining good receive batching is pretty easy. >>> >> Batching is poor mans throughput (its easy when you dont care about >> latency), so we generally avoid as much as possible. >> > > Fair enough. > >>> Considering >>> these are lightweight exits (on the order of 1-2us), >>> >> APIC EOIs on x86 are MMIO based, so they are generally much heavier than >> that. I measure at least 4-5us just for the MMIO exit on my Woodcrest, >> never mind executing the locking/apic-emulation code. >> > > You won't like to hear me say this, but Woodcrests are pretty old and > clunky as far as VT goes :-) Fair enough. > > On a modern Nehalem, I would be surprised if an MMIO exit handled in the > kernel was muck more than 2us. The hardware is getting very, very > fast. The trends here are very important to consider when we're looking > at architectures that we potentially are going to support for a long time. The exit you do not take will always be infinitely faster. > >>> you need an awfully >>> large amount of interrupts before you get really significant performance >>> impact. You would think NAPI would kick in at this point anyway. >>> >>> >> Whether NAPI can kick in or not is workload dependent, and it also does >> not address coincident events. But on that topic, you can think of >> AlacrityVM's interrupt controller as "NAPI for interrupts", because it >> operates on the same principle. For what its worth, it also operates on >> a "NAPI for hypercalls" concept too. >> > > The concept of always batching hypercalls has certainly b
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/2009 11:33 AM, Andi Kleen wrote: We're not talking about vaporware. vhost-net exists. Is it as fast as the alacrityvm setup then e.g. for network traffic? Last I heard the first could do wirespeed 10Gbit/s on standard hardware. I'm very wary of any such claims. As far as I know, no one has done an exhaustive study of vbus and published the results. This is why it's so important to understand why the results are what they are when we see numbers posted. For instance, check out http://www.redhat.com/f/pdf/summit/cwright_11_open_source_virt.pdf slide 32. These benchmarks show KVM without vhost-net pretty closely pacing native. With large message sizes, it's awfully close to line rate. Comparatively speaking, consider http://developer.novell.com/wiki/index.php/AlacrityVM/Results vbus here is pretty far off of native and virtio-net is ridiculus. Why are the results so different? Because benchmarking is fickle and networking performance is complicated. No one benchmarking scenario is going to give you a very good picture overall. It's also relatively easy to stack the cards in favor of one approach verses another. The virtio-net setup probably made extensive use of pinning and other tricks to make things faster than a normal user would see them. It ends up creating a perfect combination of batching which is pretty much just cooking the mitigation schemes to do extremely well for one benchmark. This is why it's so important to look at vbus from the perspective of critically asking, what precisely makes it better than virtio. A couple benchmarks on a single piece of hardware does not constitute an existence proof that it's better overall. There are a ton of differences between virtio and vbus because vbus was written in a vacuum wrt virtio. I'm not saying we are totally committed to virtio no matter what, but it should take a whole lot more than a couple netperf runs on a single piece of hardware for a single kind of driver to justify replacing it. Can vhost-net do the same thing? I think the fundamentally question is, what makes vbus better than vhost-net? vhost-net exists and is further along upstream than vbus is at the moment. If that question cannot be answered with technical facts and numbers to back them up, then we're just arguing for the sake of arguing. Regards, Anthony Liguori -Andi -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
* Anthony Liguori (anth...@codemonkey.ws) wrote: > The > virtio-net setup probably made extensive use of pinning and other tricks > to make things faster than a normal user would see them. It ends up > creating a perfect combination of batching which is pretty much just > cooking the mitigation schemes to do extremely well for one benchmark. Just pinning, the rest is stock virtio features like mergeable rx buffers, GRO, GSO (tx mitigation is actually disabled). Certainly doesn't show throughput in terms of cpu cycle cost (scaling) nor latency per-packet (exit and mitigation). thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On Tue, 22 Dec 2009, Gregory Haskins wrote: > On 12/22/09 2:39 PM, Davide Libenzi wrote: > > On Tue, 22 Dec 2009, Gregory Haskins wrote: > > > >> On 12/22/09 1:53 PM, Avi Kivity wrote: > >>> I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did > >>> not reply. > >>> > >> > >> BTW: the ioeventfd issue just fell through the cracks, so sorry about > >> that. Note that I have no specific issue with irqfd ever since the > >> lockless IRQ injection code was added. > >> > >> ioeventfd turned out to be suboptimal for me in the fast path for two > >> reasons: > >> > >> 1) the underlying eventfd is called in atomic context. I had posted > >> patches to Davide to address that limitation, but I believe he rejected > >> them on the grounds that they are only relevant to KVM. > > > > I thought we addressed this already, in the few hundreds of email we > > exchanged back then :) > > We addressed the race conditions, but not the atomic callbacks. I can't > remember exactly what you said, but the effect was "no", so I dropped it. ;) > > This was the thread. > > http://www.archivum.info/linux-ker...@vger.kernel.org/2009-06/08548/Re:_[KVM-RFC_PATCH_1_2]_eventfd:_add_an_explicit_srcu_based_notifier_interface Didn't that ended up in schedule_work() being just fine, and no need was there for pre-emptible callbacks? > >> 2) it cannot retain the data field passed in the PIO. I wanted to have > >> one vector that could tell me what value was written, and this cannot be > >> expressed in ioeventfd. > > > > Like might have hinted in his reply, couldn't you add data support to the > > ioeventfd bits in KVM, instead of leaking them into mainline eventfd? > > > > Perhaps, or even easier I could extend xinterface. Which is what I did ;) > > The problem with the first proposal is that you would no longer actually > have an eventfd based mechanism...so any code using ioeventfd (like > Michael Tsirkin's for instance) would break. At that point, the KVM eventfd can take care of thing so that Michael bits do not break. - Davide -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On Tue, Dec 22, 2009 at 12:36, Gregory Haskins wrote: > On 12/22/09 2:57 AM, Ingo Molnar wrote: >> * Gregory Haskins wrote: >>> Actually, these patches have nothing to do with the KVM folks. [...] >> >> That claim is curious to me - the AlacrityVM host > > It's quite simple, really. These drivers support accessing vbus, and > vbus is hypervisor agnostic. In fact, vbus isn't necessarily even > hypervisor related. It may be used anywhere where a Linux kernel is the > "io backend", which includes hypervisors like AlacrityVM, but also > userspace apps, and interconnected physical systems as well. > > The vbus-core on the backend, and the drivers on the frontend operate > completely independent of the underlying hypervisor. A glue piece > called a "connector" ties them together, and any "hypervisor" specific > details are encapsulated in the connector module. In this case, the > connector surfaces to the guest side as a pci-bridge, so even that is > not hypervisor specific per se. It will work with any pci-bridge that > exposes a compatible ABI, which conceivably could be actual hardware. This is actually something that is of particular interest to me. I have a few prototype boards right now with programmable PCI-E host/device links on them; one of my long-term plans is to finagle vbus into providing multiple "virtual" devices across that single PCI-E interface. Specifically, I want to be able to provide virtual NIC(s), serial ports and serial consoles, virtual block storage, and possibly other kinds of interfaces. My big problem with existing virtio right now (although I would be happy to be proven wrong) is that it seems to need some sort of out-of-band communication channel for setting up devices, not to mention it seems to need one PCI device per virtual device. So I would love to be able to port something like vbus to my nify PCI hardware and write some backend drivers... then my PCI-E connected systems would dynamically provide a list of highly-efficient "virtual" devices to each other, with only one 4-lane PCI-E bus. Cheers, Kyle Moffett -- 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] vhost: fix high 32 bit in FEATURES ioctls
On Tue, 22 Dec 2009 10:09:33 pm Michael S. Tsirkin wrote: > From: David Stevens > Subject: vhost: fix high 32 bit in FEATURES ioctls Thanks, applied. 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: [GIT PULL] AlacrityVM guest drivers for 2.6.33
* Anthony Liguori wrote: > On 12/22/2009 10:01 AM, Bartlomiej Zolnierkiewicz wrote: > >>new e1000 driver is more superior in architecture and do the required > >>work to make the new e1000 driver a full replacement for the old one. > >Right, like everyone actually does things this way.. > > > >I wonder why do we have OSS, old Firewire and IDE stacks still around then? > > And it's always a source of pain, isn't it. Even putting aside the fact that such overlap sucks and is a pain to users (and that 98% of driver and subsystem version transitions are done completely seemlessly to users - the examples that were cited were the odd ones out of 150K commits in the past 4 years, 149K+ of which are seemless), the comparison does not even apply really. e1000, OSS, old Firewire and IDE are hardware stacks, where hardware is a not fully understood externality, with its inevitable set of compatibility voes. There's often situations where one piece of hardware still works better with the old driver, for some odd (or not so odd) reason. Also, note that the 'new' hw drivers are generally intended and are maintained as clear replacements for the old ones, and do so with minimal ABI changes - or preferably with no ABI changes at all. Most driver developers just switch from old to new and the old bits are left around and are phased out. We phased out old OSS recently. That is a very different situation from the AlacrityVM patches, which: - Are a pure software concept and any compatibility mismatch is self-inflicted. The patches are in fact breaking the ABI to KVM intentionally (for better or worse). - Gregory claims that the AlacricityVM patches are not a replacement for KVM. I.e. there's no intention to phase out any 'old stuff' and it splits the pool of driver developers. i.e. it has all the makings of a stupid, avoidable, permanent fork. The thing is, if AlacricityVM is better, and KVM developers are not willing to fix their stuff, replace KVM with it. It's a bit as if someone found a performance problem with sys_open() and came up with sys_open_v2() and claimed that he wants to work with the VFS developers while not really doing so but advances sys_open_v2() all the time. Do we allow sys_open_v2() upstream, in the name of openness and diversity, letting some apps use that syscall while other apps still use sys_open()? Or do we say "enough is enough of this stupidity, come up with some strong reasons to replace sys_open, and if so, replace the thing and be done with the pain!". Overlap and forking can still be done in special circumstances, when a project splits and a hostile fork is inevitable due to prolongued and irreconcilable differences between the parties and if there's no strong technical advantage on either side. I havent seen evidence of this yet though: Gregory claims that he wants to 'work with the community' and the KVM guys seem to agree violently that performance can be improved - and are doing so (and are asking Gregory to take part in that effort). The main difference is that Gregory claims that improved performance is not possible within the existing KVM framework, while the KVM developers disagree. The good news is that this is a hard, testable fact. I think we should try _much_ harder before giving up and forking the ABI of a healthy project and intentionally inflicting pain on our users. And, at minimum, such kinds of things _have to_ be pointed out in pull requests, because it's like utterly important. In fact i couldnt list any more important thing to point out in a pull request. Ingo -- 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