summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2009-07-29add option to disable kvm nestedJuan Quintela2-0/+15
Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <7806fd40ba59c96bb3f5ffea106f50d055ab083d.1248207931.git.quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 512837 Obsoletes: <4d7f99b8a31f941a9e0ebeee9df079b2175c0d52.1248095797.git.quintela@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> (conditional on feature unwanted) Acked-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: pending
2009-07-29disable isapcJuan Quintela2-0/+10
Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <990391e93a5cbff18e7a16fc3b62d7f201ebbab0.1248207931.git.quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 512837 Message-Id: <990391e93a5cbff18e7a16fc3b62d7f201ebbab0.1248095797.git.quintela@redhat.com> Acked-by: "Daniel P. Berrange" <berrange@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> (conditional on feature unwanted)
2009-07-29add option to disable scsiJuan Quintela7-2/+25
Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <cbb8c524097dc4fe23ac50c7d84d048ab04d1da5.1248207931.git.quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 512837 Message-Id: <cbb8c524097dc4fe23ac50c7d84d048ab04d1da5.1248095796.git.quintela@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> RH-Upstream-status: pending Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: "Daniel P. Berrange" <berrange@redhat.com>
2009-07-29add option to disable smb user directoriesJuan Quintela3-4/+13
Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <91f3a0b8637f893c2229c00f30b9b7c91182d8e8.1248207931.git.quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 512837 Message-Id: <91f3a0b8637f893c2229c00f30b9b7c91182d8e8.1248095796.git.quintela@redhat.com> Acked-by: "Daniel P. Berrange" <berrange@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> (conditional on feature unwanted) RH-Upstream-status: pending
2009-07-28Fix hdev_open error:Juan Quintela1-1/+1
In changeset 0749b030 We introduced an assignation instead of one comparation. Bad, bad, bad reviewers (I was one of them). Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <8c94268e7c70c9ef56f89fb4eb34bb357e29da91.1248275998.git.quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 513252 RH-Upstream-status: not-applicable Acked-by: Markus Armbruster <armbru@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com>
2009-07-27enable rtc-hack by defaultJuan Quintela2-2/+11
Hi Hugh asked for this patch again. He told me on irc that danp and markmc agreed on the call to change the default. Later,Juan. Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <1248125212-27589-1-git-send-email-quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 512898 Obsoletes: <d9eef5539c347670fe914f1267f2cd5342e751e4.1248208471.git.quintela@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: "Daniel P. Berrange" <berrange@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com>
2009-07-22Use pci_reset_function() in RHEL5.4 so FLR done properly (v2)Don Dutile1-0/+2
Currently on RHEL5.4, libvirt's PCI device assignment code skips performing a set of PCI config cycle operations to perform a Function Level Reset (FLR) if it detects (reads PCI config hdr fields) that a PCIe device supports FLR -- libvirt assumes KVM will call the kernel's PCI support to do an FLR to a device that supports it when KVM does device assignment and deassignment to/from a FV guest. Well, as the previous BZ, 510805, just added FLR into RHEL5.4, without this patch, if a PCIe FLR device is given or taken away from a FV guest, it is not properly reset. This can cause odd system behavior.... like crashing the host... if the device is not quiesced properly by the guest OS driver on startup or shutdown. The simple fix is to conditionally compile *out* the pci_reset_function() that is stubbed to do nothing in KVM's kernel/external-module-compat-comm.h if the kernel is < 2.6.28 (when pci_reset_function() was introduced), and it's RHEL5.4 or higher. Simple backport of what Chris Wright gave me a few weeks ago, but backported to latest head of git tree (38a1e6fb3293f47698209077a8d4907d7b8e7685). Testing: Chris Wright tested his kvm modules with this patch included along with a brew-built RHEL5.4 kernel I provided with FLR support (pci_reset_function()) that also had additional trace points (printk's) to ensure the proper code flows were exec'd for FLR & non-FLR devices. [It was printk's or a really *snappy* 2.5Gbit PCIe analyzer to decode PCI config cycle writes, link reset transitions, etc. ... ah, the good ole days...] Mark McLoughlin wrote: >> #endif >> >> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) >> +#if defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE < RHEL_RELEASE_VERSION(5,4) > > Should be > > #if !defined(RHEL_RELEASE_CODE) || RHEL_RELEASE_CODE < RHEL_RELEASE_VERSION(5,4) > > Very minor issue, I know > > Cheers, > Mark. > Based on above feedback as well as Eduardo's, attached is more correct patch for upstream & RHEL5. Please review & ACK this V2 update (esp. if you ack'd the first version). - Don Message-ID: <4A5F6D27.8070701@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 510806 RH-Upstream-status: pending Obsoletes: <4A5E2CD6.8010006@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Mark McLoughlin <markmc@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Chris Wright <chrisw@redhat.com>
2009-07-22virtio_net: remove the tx mitigation timerMark McLoughlin2-38/+36
https://bugzilla.redhat.com/504647 The tx mitigation timer is designed to reduce the rate of guest exits thereby improving throughput. However, we have identified a number of cases where mitigation hurts throughput and benchmarking has show that it only helps throughput in a very limited number of cases. This may be due to the fact that in RHEL5, the timer is effectively 1ms rather than 150us, since we don't have high resolution timers. This patch firstly removes the timer and replaces it with a bottom half. When the host is notified of a packet on the tx queue, it schedules a bottom half in the I/O thread in order to flush the queue. Next, it disables enabling notifications until it has flushed the queue. In order to avoid a race condition with this, it flushes the queue a second time when notifications are re-enabled. Finally, if it successfully flushed a number of packets in the bottom half, it disables notifications re-schedules the bottom half to quickly flush the queue again. Migration is handled by equating the tx_timer_active savevm field to tx_bh_scheduled. Signed-off-by: Mark McLoughlin <markmc@redhat.com> Message-Id: <1248193513.7126.12.camel@blaa> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 504647 Acked-by: Mark Wagner <mwagner@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com>
2009-07-21Disable hpet by default (there is no way to enable it back)Juan Quintela1-1/+1
Hi By popular demand (a.k.a. Eduardo and Dor), this is the 3rd version of this patch. Instead of compiling out hpet, we just change no_hpet value and as there is no way to change it back to 0, we know there is no hpet support at all. It supports Eduardo requirement that -no-hpet command option continues to be accepted (it does nothing). Later, Juan. Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <5fcc6e926424f3d313d3a10fc6b71d92061b034a.1248162151.git.quintela@redhat.com> Obsoletes: <2a8181609ab3a4aad27335f1787f585e84849c90.1248129474.git.quintela@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 512894 Obsoletes: <1248125240-27634-1-git-send-email-quintela@redhat.com> Acked-by: "Daniel P. Berrange" <berrange@redhat.com> Acked-by: Chris Wright <chrisw@redhat.com> Acked-by: Glauber Costa <glommer@redhat.com>
2009-07-21Set the iothread's eventfd/pipe descriptors to non-blockingDor Laor1-10/+14
It replaces the previous fix of using select. Fixes BZs: 511199, 507659 for sure, maybe 511031 Marcelo applied it to the upstream repository. >From a2567128932437d286abc82ef8f79519f9992d74 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor@redhat.com> Date: Wed, 15 Jul 2009 17:53:16 +0300 Subject: [PATCH] Set the iothread's eventfd/pipe descriptors to non-blocking. It fixes migration issue when the destination is loaded. If the migration socket is full, we get EAGAIN for the write. The set_fd_handler2 defers the write for later on. The function tries to wake up the iothread by qemu_kvm_notify_work. Since this happens in a loop, multiple times, the pipe that emulates eventfd becomes full and we get a deadlock. Mark McLoughlin suggested to remove spurious wake-up of the migration code when we get EAGAIN and wait for the socket to become writeable. (+1) Nevertheless, the pipe descriptors shouldn't be blocking and the reader can also read several chunks in a time. Signed-off-by: Dor Laor <dor@redhat.com> Message-ID: <4A62E80E.6030401@redhat.com> Obsoletes: <4A5DF084.3080305@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 511199 Bugzilla: 507659 Bugzilla-related: 511031 Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Mark McLoughlin <markmc@redhat.com> Acked-by: Glauber Costa <glommer@redhat.com>
2009-07-21fix for bug #507942 : bad macaddr of e1000 in Windows 2003 server with ↵Naphtali Sprei1-0/+3
original Microsoft driver Minor comment change (to last sent patch) and fixed WS issue of the patch. The sequence of reading from eeprom is "offset by one" moved because of a false detection of a clock cycle after an eeprom reset. Keeping the last clock value after a reset keeps it in sync. Signed-off-by: Naphtali Sprei <nsprei@redhat.com> Message-ID: <4A5EE609.3090104@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 507942 Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com>
2009-07-16kvmtrace: update formatsMarcelo Tosatti1-0/+1
Update formats with RMAP_NUKE information. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Bugzilla: 508776 Message-ID: <20090702205507.GB19631@amt.cnet> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Glauber Costa <glommer@redhat.com> Acked-by: john cooper <john.cooper@redhat.com>
2009-07-15net: add '-net tap,sndbuf=' option with a sensible defaultMark McLoughlin3-18/+156
https://bugzilla.redhat.com/508861 In a bridged configuration, we should avoid overflowing the physical NIC's TX queue and dropping packets. The 5.4 kernel adds a new TUNSETSNDBUF ioctl() which allows a send buffer limit for the tap device to be specified. When this limit is reached, a tap write() will return EAGAIN and poll() will indicate the fd isn't writable. See: https://bugzilla.redhat.com/495863 This allows people to tune their setups so as to avoid e.g. UDP packet loss when the sending application in the guest out-runs the NIC in the host. For best effect, sndbuf= should be set to just below the capacity of the physical NIC. Setting it higher will cause packets to be dropped before the limit is hit. Setting it much lower will not cause any problems unless you set it low enough such that the guest cannot queue up new packets before the NIC has emptied its queue. In Linux, txqueuelen=1000 by default for ethernet NICs. Given a 1500 byte MTU, 1Mb is a good choice for sndbuf. If it turns out that txqueuelen is actually much lower than this, then sndbuf is essentially disabled. In the event that txqueuelen is much higher, it's unlikely that the NIC will be able to empty a 1Mb queue. Also, note that when using a bridge with netfilter enabled, we currently never get EAGAIN because netfilter causes the packet to be immediately orphaned. Set /proc/sys/net/bridge/bridge nf-call-iptables to zero to disable this behaviour. The sndbuf= parameter is upstream as of this commit: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=0df0ff6de7 I've just now sent a patch upstream to set a default value. The proposed patch for 5.4 isn't a simple cherry-pick of the code from upstream, as upstream has an internal API for buffering which would have been too invasive to backport. Signed-off-by: Mark McLoughlin <markmc@redhat.com> Message-Id: <1246356077.3749.34.camel@blaa> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 508861 RH-Upstream-status: backported-from-upstream Acked-by: Herbert Xu <herbert.xu@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: "Michael S. Tsirkin" <mst@redhat.com>
2009-07-13Windows virtio driver cannot pass WHQL certification testsDor Laor1-1/+1
while the storage class is PCI_CLASS_STORAGE_UNKNOWN. QEMU upstream will use this default for 0.11. http://lists.gnu.org/archive/html/qemu-devel/2009-07/threads.html#00478 We do not have backward compatibility issue for qemu/kvm, so it can be hardcoded BZ 497058 Signed-off-by: Dor Laor <dor@redhat.com> Message-ID: <4A55B9F3.8050006@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 497058 Acked-by: Mark McLoughlin <markmc@redhat.com> Acked-by: Glauber Costa <glommer@redhat.com> Acked-by: john cooper <john.cooper@redhat.com>
2009-07-13KSM suspend fixAndrea Arcangeli1-1/+2
Can somebody with a laptop with functional suspend to ram test the below? This was reported on #kvm on irc. Against kvm-userland-rhel5. ------ this add try_to_freeze() call to the ksm thread control function to allow suspend. Signed-off-by: Chris Wright <chrisw@redhat.com> Signed-off-by: Izik Eidus <ieidus@redhat.com> Message-ID: <20090623161610.GA4379@random.random> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 505440 RH-Upstream-status: pending Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com>
2009-07-10fix bug #506375Izik Eidus1-1/+3
This patch fix bug #506375 by adding cond_resched() >From a0d889214acdafe1673f3afa4985600e345b0684 Mon Sep 17 00:00:00 2001 From: Izik Eidus <ieidus@redhat.com> Date: Wed, 17 Jun 2009 01:15:55 -0400 Subject: [PATCH] ksm: fix bug #506375 - add cond_resched() This patch fix bug #506375 by adding cond_resched() Thanks. Signed-off-by: Izik Eidus <ieidus@redhat.com> Message-ID: <4A4A2CA8.1040403@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 506375 RH-Upstream-status: not-applicable Acked-by: Andrea Arcangeli <aarcange@redhat.com> Acked-by: Glauber Costa <glommer@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com>
2009-07-10Change default CPU model to model=6 (skype fix #2)Eduardo Habkost1-2/+2
This reverts commit 34716722bf33acd7adf01f9640456e73f4d30831, and includes the following change, from Andrea Arcangeli: -------------- enable sysenter on 32bit guests (skype fix) #2 Update, see comment on model=3... such subtle details there seem to be in windows, and then somebody on qemu-devel thought they could use a brand not-existing qemu new vendor_id != intel/amd with the potential for bigger screwup of all the guest OS... (not just windows) to fix this ;). NOTE: you should check the patch applied with no offset-warnings because this risks to go to modify some other cpu definition and not qemu64 if there are offsets (if applied on current source it changes athlon because qemu64 is 6,3,3 in rhel5/master). This is not against rhel5/master but against rhel5/master minus the previous version of this patch and it obsoletes the previous patch. I guess it also invalidates all my testing (however intel/windows32 + skype has already been tested, and linux32/64 is sure fine as well on intel). I think I only need to re-test windows32+skype on svm and linux32 on svm, and linux64 with compatibility mode again on svm. ------------ From: Andrea Arcangeli <aarcange@redhat.com> model=2 is not existent when vendor is intel and an errata of P6 says that any model <= 2 when family is 6 lack sap feature, so windows and linux 32bit guests disable sap in software and slowdown for no good reason when running inside kvm on intel CPU. model=3 would fix sysenter troubles but it prevents windows XP from using all cpus, so model=6 matches "Athlon (PM core)" on AMD and "P2 with on-die L2 cache" on Intel and it allows windows to use all CPUs as well as fixing sysenter. Patch will follow, workaround without this fix is -cpu qemu64,model=6. There is a bug in skype that it checks if the sep feature is set to run sysenter on intel chip inside its binary without passing through ntdll, without verifying the model was <= 2 like windows does, so windows forbids sysenter but skype calls it anyway. This is skype bug and it would trigger on real P6 hardware too (but nobody tests skype on P6). qemu64,-sep fixed skype. But because every time we have an intel cpu running kvm, we also have sysenter functioning, we boots the model to 6 so windows 32bit (and linux32bit) gets a boost with sysenter too. Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Message-ID: <20090702135142.GN9711@blackpad> Message-ID: <20090702124933.GW14272@random.random> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 508623 Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: Glauber Costa <glommer@redhat.com>
2009-07-10provide stop reason on demandGleb Natapov11-9/+33
Store VM stop reason and provide it on monitor by demand. Upstream status: not upstream. Never will be. BZ: 505999 Signed-off-by: Gleb Natapov <gleb@redhat.com> Message-ID: <20090701110724.GA27539@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 505999 RH-Upstream-status: not-applicable Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> Acked-by: Glauber Costa <glommer@redhat.com>
2009-07-10make vnc socket non-blockingGleb Natapov1-0/+1
QEMU event loop main_loop_wait() can be called recursively (main_loop_wait()->tcp_chr_read_poll()->do_change_vnc()->monitor_readline()->main_loop_wait()) and because of this an io callback can be called more then once for single IO event. That is why the callback can't assume that file is readable or writable and should always mark it as no-blocking and handle EAGAIN error. Upstream status: the recursion does not exists in upstream any more. Signed-off-by: Gleb Natapov <gleb@redhat.com> Message-ID: <20090624155258.GH20289@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 507880 RH-Upstream-status: not-applicable Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Glauber Costa <glommer@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com>
2009-07-07Fix eepro100 segfault during live migrate after NIC hot-unplugMark McLoughlin2-0/+23
https://bugzilla.redhat.com/500980 eepro100 registers a savevm handler which is not removed when the NIC is hot-unplugged. This patch just cherry-picks eepro100 bits from: http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=a34b6eb776 I've just now sent the eeprom savevm bit upstream. Signed-off-by: Mark McLoughlin <markmc@redhat.com> Message-Id: <1246486399.598.96.camel@blaa> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 500980 RH-Upstream-status: applied Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Don Dutile <ddutile@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com>
2009-07-07Fix ne2k_pci segfault during live migrate after NIC hot-unplugMark McLoughlin1-0/+8
https://bugzilla.redhat.com/500977 ne2k_pci registers a savevm handler which is not removed when the NIC is hot-unplugged. This patch just cherry-picks ne2k_pci bits from: http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=a34b6eb776 Signed-off-by: Mark McLoughlin <markmc@redhat.com> Message-Id: <1246486398.598.95.camel@blaa> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 500977 RH-Upstream-status: applied Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Don Dutile <ddutile@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com>
2009-07-07Fix rtl8139 segfault during live migrate after NIC hot-unplugMark McLoughlin1-0/+29
https://bugzilla.redhat.com/500978 rtl8139 registers a savevm handler which is not removed when the NIC is hot-unplugged. This patch just cherry-picks rtl8139 bits from: http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=a34b6eb776 Signed-off-by: Mark McLoughlin <markmc@redhat.com> Message-Id: <1246486395.598.94.camel@blaa> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 500978 RH-Upstream-status: applied Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Don Dutile <ddutile@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com>
2009-07-07net: avoid leaking VLANClientState on PCI NIC hot removeMark McLoughlin8-6/+8
https://bugzilla.redhat.com/500977 https://bugzilla.redhat.com/500978 https://bugzilla.redhat.com/500980 In device-hotplug.c:destroy_nic() we require: a) NICInfo::private matches the PCIDevice being removed and b) VLANClientState::opaque also matches the PCIDevice In the case of rtl8139, ne2k_pci and eepro100, the vc->opaque pointer isn't actually to a PCIDevice. Fix the problem by making the relationship between a NICInfo and it's corresponding VLANClientState much more clear rather than finding it via fragile pointer matching. The upstream code has changed a bit in this area, but I've suggested a similar fix upstream: http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00049.html Signed-off-by: Mark McLoughlin <markmc@redhat.com> Message-Id: <1246486394.598.93.camel@blaa> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 500977 Bugzilla: 500978 Bugzilla: 500980 RH-Upstream-status: similar-fix-submitted Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Don Dutile <ddutile@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com>
2009-07-02New command line option -balloonMarkus Armbruster3-1/+28
Backported from upstream, with the addr= feature dropped. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <87y6r9wcp4.fsf@pike.pond.sub.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 503790 RH-Upstream-status: backport-from-upstream Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com>
2009-07-02Remove broken command line option -balloonMarkus Armbruster1-16/+0
It clashes with upstream's -balloon. Crept in with -vmchannel in commit af595fab. Originally came from qemu-kvm, but is long gone there. Doesn't work, because commit af595fab failed to put it in qemu_options[] (looks like a conflict resolution accident). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <87zlbpwcpc.fsf@pike.pond.sub.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 503790 RH-Upstream-status: not-applicable Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com>
2009-07-02Revert "Disable virtio-balloon (bz#500453)"Eduardo Habkost2-3/+8
This reverts commit 6837d24e15e9791b481da71a9502425b2d2f2bed. We'll disable balloon with the new command line option -balloon instead. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-ID: <871vp1xra7.fsf@pike.pond.sub.org> RH-Upstream-status: not-applicable Bugzilla: 503790 Message-Id: <1244663681-5244-2-git-send-email-ehabkost@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com>
2009-06-30vnc: rework VncState release workflow.Gerd Hoffmann1-43/+69
Hi, Split socket closing and releasing of VncState into two steps. First close the socket and set the variable to -1 to indicate shutdown in progress. Do the actual release in a few places where we can be sure it doesn't cause trouble in form of use-after-free. Add some checks for a valid socket handle to make sure we don't try to use the closed socket. BZ #505641. Upstream status: broken too, just mailed a similar patch to qemu-devel. please ack, Gerd >From 4fa3a74a71d4f2a8b0e3389d2275b03c4d582cff Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann <kraxel@redhat.com> Date: Tue, 16 Jun 2009 11:49:33 +0200 Subject: [PATCH] vnc: rework VncState release workflow. Split socket closing and releasing of VncState into two steps. First close the socket and set the variable to -1 to indicate shutdown in progress. Do the actual release in a few places where we can be sure it doesn't cause trouble in form of use-after-free. Add some checks for a valid socket handle to make sure we don't try to use the closed socket. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-ID: <4A378FE2.5070706@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 505641 RH-Upstream-status: similar-patch-submitted(qemu-devel) Acked-by: john cooper <john.cooper@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Kevin Wolf <kwolf@redhat.com>
2009-06-30bz#505090: Guess host device type from requested guest device typeCole Robinson1-3/+8
RHEL bug: https://bugzilla.redhat.com/show_bug.cgi?id=505090 Clone of the following Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=473154 [ehabkost: comments from Cole Robinson on bugzilla are pasted below] > I just went digging through the qemu code, and I think the fix should really be > at that level. > > The code is already capable of being launched with an empty cdrom device > attached to it. Unfortunately qemu only enables this mode for cdrom devices if > the passed path starts with '/dev/cd': in the above case, we are using /dev/sr0 > :( Yay robustness. > > Patch basically says "If the user requests a cdrom/floppy device, and the > passed path is a block or char device, assume the path is a host cdrom/floppy > device." This would change some existing behavior: for example, a host block > device that is passed to a qemu guest as a cdrom is now assumed to be a host > cdrom, even when it isn't. My guess is this won't yield any real functional > change, since the only differences between floppy/cdrom and everything else (in > this case) is in the ejectable media commands. > > I haven't done much testing besides verifying that qemu no longer complains > about accessing the empty /dev/sr0. [ehabkost: patch was sent to qemu-devel at: http://marc.info/?l=qemu-devel&m=124458617900905 However, the code on the upstream qemu tree is different now, and the patch will need to be ported when submitted again.] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 505090 RH-Upstream-status: equivalent-patch-submitted(qemu-devel) Message-Id: <1245185205-9600-1-git-send-email-ehabkost@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: john cooper <john.cooper@redhat.com>
2009-06-23enable sysenter on 32bit guests (skype fix)Andrea Arcangeli1-1/+2
NOTE: this is untested on AMD at this time, duron should work as well as athlon, they're in the same family but giving a spin on skype over xpsp2 on amd with this patch is good idea before commit even if review passes. From: Andrea Arcangeli <aarcange@redhat.com> model=2 is not existent when vendor is intel and an errata of P6 says that any model <= 2 when family is 6 lack sap feature, so windows and linux 32bit guests disable sap in software and slowdown for no good reason when running inside kvm on intel CPU. Fix is to set model = 3 so it'll be the duron cpu when kvm runs on amd bare metal (not anymore athlon but userland doesn't see the difference) and it'll be PII that has sysenter functional like all cpus that run KVM have too when on intel bare metal. Patch will follow, workaround without this fix is -cpu qemu64,model=3. There is a bug in skype that it checks if the sep feature is set to run sysenter on intel chip inside its binary without passing through ntdll, without verifying the model was <= 2 like windows does, so windows forbids sysenter but skype calls it anyway. This is skype bug and it would trigger on real P6 hardware too (but nobody tests skype on P6). qemu64,-sep fixed skype. But because every time we have an intel cpu running kvm, we also have sysenter functioning, we boots the model to 3 so windows 32bit (and linux32bit) gets a boost with sysenter too. Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Message-ID: <20090618174044.GU12816@random.random> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Rik van Riel <riel@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Acked-by: Amit Shah <amit.shah@redhat.com> Bugzilla: 504628
2009-06-22Add qemu-img check subcommandKevin Wolf5-29/+160
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=506017 This patch consists of four commits in upstream qemu: qcow2: Fix warnings in check_refcount() (Kevin Wolf) This code is currently only compiled when DEBUG_ALLOC is defined, so you usually don't see compiler warnings on it. This patch series wants to enable the code, so fix the format string warnings first. While we're at it, let's print error messages to stderr. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7213 c046a42c-6fe2-441c-8c8c-71466251a162 --- Introduce bdrv_check (Kevin Wolf) Introduce a new bdrv_check function pointer for block drivers. Modify qcow2 to return an error status in check_refcounts(), so it can implement bdrv_check. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7214 c046a42c-6fe2-441c-8c8c-71466251a162 --- Introduce qemu-img check subcommand (Kevin Wolf) Now that block drivers can provide check functions, expose them through qemu-img. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7215 c046a42c-6fe2-441c-8c8c-71466251a162 --- qcow2: Add plausibility check for L1/L2 entries (Kevin Wolf) All L1 and L2 entries must point at the start of a cluster. If there is some offset into the cluster, the entry is corrupted. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7217 c046a42c-6fe2-441c-8c8c-71466251a162 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <1245249892-28638-1-git-send-email-kwolf@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 506017 RH-Upstream-status: applied(qemu/master) Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Gleb Natapov <gleb@redhat.com>
2009-06-22Fix vga_screen_dump_blank() PPM generation (bz#500717)Eduardo Habkost1-2/+3
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=500717 vga_screen_dump_blank() was not generating a valid PPM file: the width of the image made no sense (why it was multiplied by sizeof(uint32_t)?), and there was only one sample per pixel, instead of three. Fixing it will improve the reliability of our internal testing, by solving a kvm-autotest issue. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> Bugzilla: 500717 RH-Upstream-status: applied(qemu/master) Message-ID: <20090619213933.GA5213@blackpad> Acked-by: Uri Lublin <uril@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com>
2009-06-19Correctly assign apic ids for hotplugged cpusGleb Natapov1-1/+0
BIOS assumes that apic ids are continuous from 0 to max cpus when it builds its acpi/mptable tables, but QEMU allocates one id for ioapic, so hot plugged cpus are created with apic id skewed by one. OS cannot communicate with newly created cpu since the apic id of new cpu is not the same as what ACPI tells to an OS. Do not allocate apic id to ioapic. This shouldn't be done by QEMU anyway. This is BIOS or OS job. Upstream status: not needed. The code was rearranged and this line is not exist any more. BZ: 504581 (part of it. Should fix f10. rhel5.3 does not support cpu hot-plug) Signed-off-by: Gleb Natapov <gleb@redhat.com> Message-ID: <20090616084444.GQ19508@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: not-needed Acked-by: Glauber Costa <glommer@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Acked-by: Don Dutile <ddutile@redhat.com> Bugzilla: 504237
2009-06-19bios: Fix missing DMI table entriesMarkus Armbruster1-5/+6
Upstream qemu-kvm commit 12766cd6 can make the BIOS to swallow DMI table entries. I observed it swallowing one of two CPUs by booting from RHEL-3.8 installation media and running dmidecode. With the patch applied, dmidecode shows both CPUs again. Patch snatched from qemu-devel, where it has been ignored so far (I posted a nudge): From: Alex Williamson <alex.williamson@hp.com> Subject: [Qemu-devel] [PATCH RESEND] bios: Fix multiple calls into smbios_load_external() To: qemu-devel <qemu-devel@nongnu.org> Cc: Beth Kon <eak@us.ibm.com> Date: Mon, 15 Jun 2009 09:41:32 -0600 Message-Id: <1243528568.25164.47.camel@bling> Organization: OSLO R&D We're marking the used entry bitmap in smbios_load_external() for each type we check, regardless of whether we loaded anything. This makes subsequent calls behave as if we've already loaded the tables from qemu and can result in missing tables (ex. multiple type4 entries on an SMP guest). Only mark the bitmap if we actually load something. Signed-off-by: Alex Williamson <alex.williamson@hp.com> Bug 504713, please ACK. Message-ID: <87skhy6efg.fsf@pike.pond.sub.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 504713 RH-Upstream-status: submitted(qemu-devel) Acked-by: Zachary Amsden <zamsden@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Acked-by: Gleb Natapov <gleb@redhat.com>
2009-06-16Register uhci_reset() callback.Gleb Natapov1-0/+3
Update IRQ line on reset. Upstream status: posted for review BZ: 500796 Signed-off-by: Gleb Natapov <gleb@redhat.com> Message-ID: <20090611084948.GB19508@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: submitted Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Bugzilla: 504237
2009-06-16Add reset to rtl8139 nic.Gleb Natapov1-1/+3
Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> Message-Id: <1244635966-21609-3-git-send-email-gleb@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: applied(qemu/master) Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Bugzilla: 504237
2009-06-16Add reset to e1000 nic.Gleb Natapov1-7/+24
Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> Message-Id: <1244635966-21609-2-git-send-email-gleb@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: applied(qemu/master) Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Bugzilla: 504237
2009-06-15fix unresigered vbe physical mapping as reserved memory in the biosIzik Eidus1-4/+13
Hey, The vbe was not registered as reserved memory, and therefore windows was able to try to map pci devices into this address range. Thanks. >From e454420497aec9e77b0e7a1d20e101f9b4015bc2 Mon Sep 17 00:00:00 2001 From: Izik Eidus <ieidus@redhat.com> Date: Thu, 11 Jun 2009 11:08:03 -0400 Subject: [PATCH] bios: fix vbe unregistered mapping to e820. The vbe was not registered as reserved memory, and therefore windows was able to try to map pci devices into this address range. Thanks. Signed-off-by: Izik Eidus <ieidus@redhat.com> Message-ID: <4A30D0C4.3000405@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Bugzilla: 504237
2009-06-15Add rtc reset function.Gleb Natapov1-0/+25
On reset: Periodic Interrupt Enable (PIE) bit is cleared to zero Alarm Interrupt Enable (AIE) bit is cleared to zero Update ended Interrupt Flag (UF) bit is cleared to zero Interrupt Request status Flag (IRQF) bit is cleared to zero Periodic Interrupt Flag (PF) bit is cleared to zero Alarm Interrupt Flag (AF) bit is cleared to zero Square Wave output Enable (SQWE) zero Signed-off-by: Gleb Natapov <gleb@redhat.com> Message-Id: <1244635966-21609-4-git-send-email-gleb@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: submitted Obsoletes: <20090608135639.GH27210@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: Avi Kivity <avi@redhat.com> Bugzilla: 504237
2009-06-08vdi_port: call disconnect on reset #504463Yaniv Kamay1-3/+3
Hi, Attaching patch for bug 504463 Thanks, Yaniv >From bfc16ca2322cbe9b98b18271422207527b14dbd6 Mon Sep 17 00:00:00 2001 From: Yaniv Kamay <ykamay@redhat.com> Date: Sun, 7 Jun 2009 14:47:14 +0300 Subject: [PATCH] vdi_port: call disconnect on reset #504463 Message-ID: <4A2C2132.8080500@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: not-applicable Acked-by: Izik Eidus <ieidus@redhat.com> Acked-by: Arnon Gilboa <agilboa@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Bugzilla: 504237
2009-06-08KSM: avoid losing (but no mem leak) rmap_items inside ksm data strcturesIzik Eidus1-3/+4
The implication of this should be minor (worst case is to lose visibility on some pages in stable tree, no crash, no memleak, just no merging of pages). The tree_item->rmap_item is the head of the list and as such it must not be overwritten except in the case that the element we removed (rmap_item) was the previous head of the list, in which case it would also have rmap_item->prev set to null. This was only found by reading source while fixing the crash with slab debug enabled. For rhev/master and rhel5/master. Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Izik Eidus <ieidus@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: not-applicable Message-Id: <1243894307-17932-5-git-send-email-ieidus@redhat.com> Message-Id: <1244142579-3405-4-git-send-email-ieidus@redhat.com> Acked-by: Andrea Arcangeli <aarcange@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Bugzilla: 504237
2009-06-08exec-migration: handle EINTR in popen_get_buffer() (v3)Uri Lublin1-1/+8
Sometimes, upon interrupt, fread returns with no data, and the (incoming exec) migration fails. Fix by retrying on such a case. Changes from v2: using clearerr and ferror using a local variable fp bz 501693 Signed-off-by: Uri Lublin <uril@redhat.com> Message-Id: <1244475604-25852-1-git-send-email-uril@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: pending Obsoletes: <1243956781-29993-5-git-send-email-uril@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Gleb Natapov <gleb@redhat.com> Bugzilla: 504237
2009-06-08asynchronous notifications: add "all" event (v3)Uri Lublin1-10/+18
Instead of setting one by one just "notify all on/off" in qemu monitor or start with '-notify all'. Changes from v2: Replaced memset() with a for loop. bz 501693 Signed-off-by: Uri Lublin <uril@redhat.com> Message-Id: <1244464890-14761-1-git-send-email-uril@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: not-applicable Obsoletes: <1243956781-29993-4-git-send-email-uril@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Gleb Natapov <gleb@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Bugzilla: 504237
2009-06-08migration: exec: notify upon successful completion of migration (v2)Uri Lublin1-0/+1
bz 501693 Signed-off-by: Uri Lublin <uril@redhat.com> Message-Id: <1243956781-29993-2-git-send-email-uril@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: not-applicable Obsoletes: <1243182659-8254-3-git-send-email-uril@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: "Michael S. Tsirkin" <mst@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Bugzilla: 504237
2009-06-08qemu: add "-notify" command line option to enable async notifications (v2)Uri Lublin2-3/+35
Use "-notify <event>" similar to "notify event on" monitor command. All "notify" monitor-command events are supported. Exits upon a bad event. Needed for receiving notifications (e.g. upon migration completion on the destination) especially for (incoming) migration from file. bz 501693 Signed-off-by: Uri Lublin <uril@redhat.com> Message-Id: <1243956781-29993-3-git-send-email-uril@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: not-applicable Obsoletes: <1243182659-8254-2-git-send-email-uril@redhat.com> Acked-by: john cooper <john.cooper@redhat.com> Acked-by: "Michael S. Tsirkin" <mst@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Bugzilla: 504237
2009-06-08migrate_fd_close: delete associated io-handler before closing the fdUri Lublin1-0/+2
It may happen that the io-handler is still registered. That causes select() to return with EBADF, not calling handlers for other fds. The io-handler would be registered when (on the source) the whole state was written but not yet flushed. For example when using QEMUFileBuffered, (tcp-migration) there may be data left in a buffer waiting to be transferred. In such a case buffered_close() calls buffered_flush() which calls migrate_fd_put_buffer, which may, upon EAGAIN, register migrate_fd_put_notify as a handler. BZ 503713 Signed-off-by: Uri Lublin <uril@redhat.com> Message-Id: <1244460597-13647-1-git-send-email-uril@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: pending Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Acked-by: Mark McLoughlin <markmc@redhat.com> Bugzilla: 504237
2009-06-08spice: change vendor id #504190Yaniv Kamay2-7/+7
Hi, Attaching patch that change PCI vendor id from Qumranet 0x1af4 to RedHat 0x1b36. BZ #504190 Thanks, Yaniv >From 1a27b95e9262af59c9c2a2bc58b87726e898e288 Mon Sep 17 00:00:00 2001 From: Yaniv Kamay <ykamay@redhat.com> Date: Thu, 4 Jun 2009 22:44:07 +0300 Subject: [PATCH 1/2] spice: change vendor id #504190 Message-ID: <4A2CD80B.1020200@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> RH-Upstream-status: not-applicable Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Izik Eidus <ieidus@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com> Bugzilla: 504237
2009-06-08fix qemu_aio_flushAndrea Arcangeli2-5/+10
This is for all kvm-userland-rhel5 and shall fix bug #489205. ---- From: Andrea Arcangeli <aarcange@redhat.com> qemu_aio_wait by invoking the bh or one of the aio completion callbacks, could end up submitting new pending aio, breaking the invariant that qemu_aio_flush returns only when no pending aio is outstanding (possibly a problem for migration as such). Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Message-ID: <20090604134122.GV25483@random.random> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Gleb Natapov <gleb@redhat.com> Acked-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Bugzilla: 504237
2009-06-08kvm doesn't build on newer RHEL-5.4 kernels because of ↵john cooper2-1/+18
get_user_pages_fast(), AKA BZ #504047, V2 [Bug fix of prior version where gupf() compat conversion was broken for !rhel5.4] This patch reverts the interim suboptimal work-around for get_user_pages_fast() and smp_send_reschedule() under RHEL5.4 kernels where both symbols are now exported to module linkage (ref: BZ #504038). Test: kernel modules should build successfully and load under a rhel5.4 kernel patched per BZ #504038. Additionally no related external-module-compat symbols should be built into modules nor referenced under a rhel5.4 host, eg: U get_user_pages_fast U smp_send_reschedule Signed-off-by: john cooper <john.cooper@redhat.com> Message-ID: <4A280149.7020807@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Bugzilla: 504047 RH-Upstream-status: pending Obsoletes: <4A27182E.2020701@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Don Dutile <ddutile@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com>
2009-06-07set migration max downtimeGlauber Costa3-0/+23
provide a monitor command to allow one to set the maximum downtime he is willing to suffer during migration, in seconds. "ms", "us", "ns" and "s" are accepted as modifiers. This parameter will be used by ram_save_live() code to determine a safe moment to enter stage 3 Signed-off-by: Glauber Costa <glommer@redhat.com> RH-Upstream-status: pending (qemu) Message-Id: <1243948209-24257-3-git-send-email-glommer@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Obsoletes: <1243925661-21880-3-git-send-email-glommer@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Uri Lublin <uril@redhat.com> Acked-by: "Michael S. Tsirkin" <mst@redhat.com> Bugzilla: 504237
2009-06-07add non-arbitrary migration stop conditionGlauber Costa3-2/+30
Currently, we're entering migration's stage 3 when a treshold of 10 pages remain to be transferred in the system. This has hurt some users. However, any proposed threshold is arbitrary by nature, and would only shift the annoyance. The proposal of this patch is to define a max_downtime variable, which represents the maximum downtime a migration user is willing to suffer. Then, based on the bandwidth of last iteration, we calculate how much data we can transfer in such a window of time. Whenever we reach that value (or lower), we know is safe to enter stage3. This has largely improved the situation for me. On localhost migrations, where one would expect things to go as quickly as me running away from the duty of writting software for windows, a kernel compile was enough to get the migration stuck. It takes 20 ~ 30 iterations now. Signed-off-by: Glauber Costa <glommer@redhat.com> RH-Upstream-status: pending (qemu) Message-Id: <1243948209-24257-2-git-send-email-glommer@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Obsoletes: <1243925661-21880-2-git-send-email-glommer@redhat.com> Acked-by: Dor Laor <dlaor@redhat.com> Acked-by: Uri Lublin <uril@redhat.com> Acked-by: "Michael S. Tsirkin" <mst@redhat.com> Bugzilla: 504237
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 20:59:56 +0000