Livebackup wiki page on wiki.qemu.org now available
It is available at: http://wiki.qemu.org/Features/Livebackup It is a work in progress, and I will continue to add control flow diagrams, and other illustrative content over the next week or so. Feedback is welcome. Thanks, Jagane -- 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 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
> >> What kind of mmio should be traced here, device or CPU originated? Or both? > >> > >> Jan > >> > >> > > > > To let Kemari replay outputs upon failover, tracing CPU originated > > mmio (specifically write requests) should be enough. > > IIUC, we can reproduce device originated mmio as a result of cpu > > originated mmio. > > Sorry, but I don't understand why it is safe yet. The problem is not if the mmio's are to be replayed but if replaying them will produce the same result, is it? In other words, is it really idempotent? Takuya > > OK, I see. > > But this tap will only work for KVM. I think you either have to catch > the other paths that TCG could take as well or maybe better move the > hook into kvm-all - then it's absolutely clear that this is no generic > feature. > > Jan > -- 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 6/7] KVM test: Try to load subtests from a shared tests location
As we have several subtests that can be shared among different
virtualization tests (kvm, xen), manipulate kvm.py to try loading
subtests from the kvm area (client/tests/kvm/tests) first,
then falling back to the specific test area (planned to be
client/virt/tests).
Changes from v1:
* Martin Jenner has suggested inverting the lookup order.
Looking first on the specific kvm subtest area *then* common
allows people to override the commom implementation of a test
that might be better for that particular virt technology.
Signed-off-by: Lucas Meneghel Rodrigues
Signed-off-by: Martin Jenner
---
client/tests/kvm/kvm.py | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py
index 2006880..bb17f28 100644
--- a/client/tests/kvm/kvm.py
+++ b/client/tests/kvm/kvm.py
@@ -59,11 +59,19 @@ class kvm(test.test):
# test type
t_type = params.get("type")
# Verify if we have the correspondent source file for it
-subtest_dir = os.path.join(self.bindir, "tests")
-module_path = os.path.join(subtest_dir, "%s.py" % t_type)
-if not os.path.isfile(module_path):
-raise error.TestError("No %s.py test file found" %
- t_type)
+virt_dir = os.path.dirname(virt_utils.__file__)
+subtest_dir_virt = os.path.join(virt_dir, "tests")
+subtest_dir_kvm = os.path.join(self.bindir, "tests")
+subtest_dir = None
+for d in [subtest_dir_kvm, subtest_dir_virt]:
+module_path = os.path.join(d, "%s.py" % t_type)
+if os.path.isfile(module_path):
+subtest_dir = d
+break
+if subtest_dir is None:
+raise error.TestError("Could not find test file %s.py "
+ "on either %s or %s directory" %
+ subtest_dir_kvm,
subtest_dir_virt)
# Load the test module
f, p, d = imp.find_module(t_type, [subtest_dir])
test_module = imp.load_module(t_type, f, p, d)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] KVM test: tests_base.cfg: Introduce parameter 'vm_type'
In order to allow the shared infrastructure to select the correct vm class to instantiate a VM, introduce the parameter vm_type, which for kvm based VMs is, not surprisingly, 'kvm'. Signed-off-by: Lucas Meneghel Rodrigues --- client/tests/kvm/build.cfg.sample |2 ++ client/tests/kvm/tests_base.cfg.sample |1 + client/tests/kvm/unittests.cfg.sample |1 + 3 files changed, 4 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/build.cfg.sample b/client/tests/kvm/build.cfg.sample index a689ed4..a43c0e9 100644 --- a/client/tests/kvm/build.cfg.sample +++ b/client/tests/kvm/build.cfg.sample @@ -7,6 +7,8 @@ #KVM test dir. # 2) The appropriate KVM modules are already loaded on your machine. +vm_type = kvm + variants: - build: type = build diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index 5d274f8..810a4bd 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -2,6 +2,7 @@ # # Define the objects we'll be using vms = vm1 +vm_type = kvm images = image1 cdroms = cd1 nics = nic1 diff --git a/client/tests/kvm/unittests.cfg.sample b/client/tests/kvm/unittests.cfg.sample index 3d32cb2..44f0eee 100644 --- a/client/tests/kvm/unittests.cfg.sample +++ b/client/tests/kvm/unittests.cfg.sample @@ -2,6 +2,7 @@ # # Define the objects we'll be using vms = vm1 +vm_type = kvm # Choose the main VM main_vm = vm1 -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] KVM autotest refactor stage 1 v3
In order to maximize code reuse among different virtualization technologies, refactor the KVM test code in a way that will allow new implementations of virtualization testing, such as xen testing. What was done • Create autotest_lib.client.virt and move the libraries in there, with some renaming and abstracting the KVM specific functions • Create a dispatcher that can instantiate the appropriate vm class, controlled by a new parameter 'vm_type' (can be kvm, xen, futurely libvirt...) • Make all the code use the new libraries • Remove the 'old' libraries • Make the KVM test loader to try finding the tests on a common location, and if the test can't be found there, look for it on the kvm subtest dir. This way other virt tests can benefit from thm • Move the tests that have virt tech agnostic code to the common location This version incorporates bugfixes and suggestions from reviewers, and hopefully will be very close to what will get upstream. My plan is to shortly freeze the tree until we can get this in. Lucas Meneghel Rodrigues (7): KVM test: Create autotest_lib.client.virt namespace KVM test: Move test utilities to client/tools KVM test: tests_base.cfg: Introduce parameter 'vm_type' KVM test: Adapt the test code to use the new virt namespace KVM test: Removing the old libraries and programs KVM test: Try to load subtests from a shared tests location KVM test: Moving generic tests to common tests area client/common_lib/cartesian_config.py | 696 ++ client/tests/kvm/build.cfg.sample |2 + client/tests/kvm/cd_hash.py| 48 - client/tests/kvm/control | 18 +- client/tests/kvm/control.parallel |8 +- client/tests/kvm/control.unittests | 14 +- client/tests/kvm/get_started.py|5 +- client/tests/kvm/html_report.py| 1727 --- client/tests/kvm/installer.py | 838 --- client/tests/kvm/kvm.py| 32 +- client/tests/kvm/kvm_config.py | 698 -- client/tests/kvm/kvm_monitor.py| 763 --- client/tests/kvm/kvm_preprocessing.py | 454 client/tests/kvm/kvm_scheduler.py | 229 -- client/tests/kvm/kvm_subprocess.py | 1351 client/tests/kvm/kvm_test_utils.py | 753 --- client/tests/kvm/kvm_utils.py | 2317 client/tests/kvm/kvm_vm.py | 1860 client/tests/kvm/migration_control.srv | 12 +- client/tests/kvm/ppm_utils.py | 237 -- client/tests/kvm/rss_file_transfer.py | 519 - client/tests/kvm/scan_results.py | 97 - client/tests/kvm/stepeditor.py | 1401 client/tests/kvm/test_setup.py | 107 - client/tests/kvm/tests/autotest.py | 25 - client/tests/kvm/tests/balloon_check.py|2 +- client/tests/kvm/tests/boot.py | 26 - client/tests/kvm/tests/boot_savevm.py |2 +- client/tests/kvm/tests/build.py|6 +- client/tests/kvm/tests/clock_getres.py | 32 - client/tests/kvm/tests/enospc.py |8 +- client/tests/kvm/tests/ethtool.py | 235 -- client/tests/kvm/tests/file_transfer.py| 83 - client/tests/kvm/tests/guest_s4.py | 76 - client/tests/kvm/tests/guest_test.py | 80 - client/tests/kvm/tests/image_copy.py | 45 - client/tests/kvm/tests/iofuzz.py | 136 -- client/tests/kvm/tests/ioquit.py | 31 - client/tests/kvm/tests/iozone_windows.py | 40 - client/tests/kvm/tests/jumbo.py| 127 -- client/tests/kvm/tests/kdump.py| 75 - client/tests/kvm/tests/ksm_overcommit.py | 37 +- client/tests/kvm/tests/linux_s3.py | 41 - client/tests/kvm/tests/mac_change.py | 60 - client/tests/kvm/tests/migration.py|6 +- .../kvm/tests/migration_with_file_transfer.py |8 +- client/tests/kvm/tests/migration_with_reboot.py|4 +- client/tests/kvm/tests/module_probe.py |4 +- client/tests/kvm/tests/multicast.py| 90 - client/tests/kvm/tests/netperf.py | 112 - client/tests/kvm/tests/nic_bonding.py |8 +- client/tests/kvm/tests/nic_hotplug.py | 24 +- client/tests/kvm/tests/nic_promisc.py | 39 - client/tests/kvm/tests/nicdriver_unload.py | 62 - client/tests/kvm/tests/pci_hotplug.py | 18 +- client/tests/kvm/tests/physical_resources_check.py |2 +- client/tes
Re: [PATCH v2] virtio_balloon: disable oom killer when fill balloon
On Wed, Apr 27, 2011 at 10:06 AM, KOSAKI Motohiro wrote: >> On Wed, Apr 27, 2011 at 9:37 AM, Dave Young >> wrote: >> > On Wed, Apr 27, 2011 at 7:33 AM, Minchan Kim wrote: >> >> On Tue, Apr 26, 2011 at 6:39 PM, Dave Young >> >> wrote: >> >>> On Tue, Apr 26, 2011 at 5:28 PM, Minchan Kim >> >>> wrote: >> Please resend this with [2/2] to linux-mm. >> >> On Tue, Apr 26, 2011 at 5:59 PM, Dave Young >> wrote: >> > When memory pressure is high, virtio ballooning will probably cause >> > oom killing. >> > Even if alloc_page with GFP_NORETRY itself does not directly trigger >> > oom it >> > will make memory becoming low then memory alloc of other processes >> > will trigger >> > oom killing. It is not desired behaviour. >> >> I can't understand why it is undesirable. >> Why do we have to handle it specially? >> >> >>> >> >>> Suppose user run some random memory hogging process while ballooning >> >>> it will be undesirable. >> >> >> >> >> >> In VM POV, kvm and random memory hogging processes are customers. >> >> If we handle ballooning specially with disable OOM, what happens other >> >> processes requires memory at same time? Should they wait for balloon >> >> driver to release memory? >> >> >> >> I don't know your point. Sorry. >> >> Could you explain your scenario in detail for justify your idea? >> > >> > What you said make sense I understand what you said now. Lets ignore >> > my above argue and see what I'm actually doing. >> > >> > I'm hacking with balloon driver to fit to short the vm migration time. >> > >> > while migrating host tell guest to balloon as much memory as it can, then >> > start >> > migrate, just skip the ballooned pages, after migration done tell >> > guest to release the memory. >> > >> > In migration case oom is not I want to see and disable oom will be good. >> >> BTW, if oom_killer_disabled is really not recommended to use I can >> switch back to oom_notifier way. > > Could you please explain why you dislike oom_notifier and what problem > you faced? I haven't understand why oom_notifier is bad. probably my > less knowledge of balloon is a reason. > Both is fine for me indeed, oom_killer_disable is more simple to use instead. I ever sent a oom_notifier patch last year and did not get much intention, I can refresh and resend it. -- Regards dave -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] virtio_balloon: disable oom killer when fill balloon
> On Wed, Apr 27, 2011 at 9:37 AM, Dave Young wrote: > > On Wed, Apr 27, 2011 at 7:33 AM, Minchan Kim wrote: > >> On Tue, Apr 26, 2011 at 6:39 PM, Dave Young > >> wrote: > >>> On Tue, Apr 26, 2011 at 5:28 PM, Minchan Kim > >>> wrote: > Please resend this with [2/2] to linux-mm. > > On Tue, Apr 26, 2011 at 5:59 PM, Dave Young > wrote: > > When memory pressure is high, virtio ballooning will probably cause oom > > killing. > > Even if alloc_page with GFP_NORETRY itself does not directly trigger > > oom it > > will make memory becoming low then memory alloc of other processes will > > trigger > > oom killing. It is not desired behaviour. > > I can't understand why it is undesirable. > Why do we have to handle it specially? > > >>> > >>> Suppose user run some random memory hogging process while ballooning > >>> it will be undesirable. > >> > >> > >> In VM POV, kvm and random memory hogging processes are customers. > >> If we handle ballooning specially with disable OOM, what happens other > >> processes requires memory at same time? Should they wait for balloon > >> driver to release memory? > >> > >> I don't know your point. Sorry. > >> Could you explain your scenario in detail for justify your idea? > > > > What you said make sense I understand what you said now. Lets ignore > > my above argue and see what I'm actually doing. > > > > I'm hacking with balloon driver to fit to short the vm migration time. > > > > while migrating host tell guest to balloon as much memory as it can, then > > start > > migrate, just skip the ballooned pages, after migration done tell > > guest to release the memory. > > > > In migration case oom is not I want to see and disable oom will be good. > > BTW, if oom_killer_disabled is really not recommended to use I can > switch back to oom_notifier way. Could you please explain why you dislike oom_notifier and what problem you faced? I haven't understand why oom_notifier is bad. probably my less knowledge of balloon is a reason. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command
On 04/26/2011 09:29 PM, Anthony Liguori wrote: > On 04/26/2011 08:26 AM, Luiz Capitulino wrote: >> On Thu, 21 Apr 2011 11:23:54 +0800 >> Lai Jiangshan wrote: >> >>> >>> Hi, Anthony Liguori >>> >>> Any suggestion? >>> >>> Although all command line interfaces will be converted to to use QMP >>> interfaces in 0.16, >>> I hope inject-nmi come into QAPI earlier, 0.15. >> >> I don't know what Anthony thinks about adding new commands like this one that >> early to the new QMP interface, but adding them to current QMP will certainly >> cause less code churn on your side. That's what I'd recommend for now. > > Yeah, sorry, this whole series has been confused in the QAPI discussion. > > I did not intend for QAPI to be disruptive to current development. > > As far as I can tell, the last series that was posted (before the QAPI post) > still had checkpatch.pl issues (scripts/checkpatch.pl btw) and we had agreed > that once that was resolved, it would come in through Luiz's tree. > Sorry, I didn't caught the meaning. Fix checkpatch.pl issues of V7 Patch, and sent it again? Thanks, Lai -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] virtio_balloon: disable oom killer when fill balloon
On Wed, Apr 27, 2011 at 9:37 AM, Dave Young wrote: > On Wed, Apr 27, 2011 at 7:33 AM, Minchan Kim wrote: >> On Tue, Apr 26, 2011 at 6:39 PM, Dave Young >> wrote: >>> On Tue, Apr 26, 2011 at 5:28 PM, Minchan Kim wrote: Please resend this with [2/2] to linux-mm. On Tue, Apr 26, 2011 at 5:59 PM, Dave Young wrote: > When memory pressure is high, virtio ballooning will probably cause oom > killing. > Even if alloc_page with GFP_NORETRY itself does not directly trigger oom > it > will make memory becoming low then memory alloc of other processes will > trigger > oom killing. It is not desired behaviour. I can't understand why it is undesirable. Why do we have to handle it specially? >>> >>> Suppose user run some random memory hogging process while ballooning >>> it will be undesirable. >> >> >> In VM POV, kvm and random memory hogging processes are customers. >> If we handle ballooning specially with disable OOM, what happens other >> processes requires memory at same time? Should they wait for balloon >> driver to release memory? >> >> I don't know your point. Sorry. >> Could you explain your scenario in detail for justify your idea? > > What you said make sense I understand what you said now. Lets ignore > my above argue and see what I'm actually doing. > > I'm hacking with balloon driver to fit to short the vm migration time. > > while migrating host tell guest to balloon as much memory as it can, then > start > migrate, just skip the ballooned pages, after migration done tell > guest to release the memory. > > In migration case oom is not I want to see and disable oom will be good. BTW, if oom_killer_disabled is really not recommended to use I can switch back to oom_notifier way. > >> And as I previous said, we have to solve oom_killer_disabled issue in >> do_try_to_free_pages. >> >> Thanks, Dave. >> -- >> Kind regards, >> Minchan Kim >> > > > > -- > Regards > dave > -- Regards dave -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] virtio_balloon: disable oom killer when fill balloon
On Wed, Apr 27, 2011 at 7:33 AM, Minchan Kim wrote: > On Tue, Apr 26, 2011 at 6:39 PM, Dave Young wrote: >> On Tue, Apr 26, 2011 at 5:28 PM, Minchan Kim wrote: >>> Please resend this with [2/2] to linux-mm. >>> >>> On Tue, Apr 26, 2011 at 5:59 PM, Dave Young >>> wrote: When memory pressure is high, virtio ballooning will probably cause oom killing. Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it will make memory becoming low then memory alloc of other processes will trigger oom killing. It is not desired behaviour. >>> >>> I can't understand why it is undesirable. >>> Why do we have to handle it specially? >>> >> >> Suppose user run some random memory hogging process while ballooning >> it will be undesirable. > > > In VM POV, kvm and random memory hogging processes are customers. > If we handle ballooning specially with disable OOM, what happens other > processes requires memory at same time? Should they wait for balloon > driver to release memory? > > I don't know your point. Sorry. > Could you explain your scenario in detail for justify your idea? What you said make sense I understand what you said now. Lets ignore my above argue and see what I'm actually doing. I'm hacking with balloon driver to fit to short the vm migration time. while migrating host tell guest to balloon as much memory as it can, then start migrate, just skip the ballooned pages, after migration done tell guest to release the memory. In migration case oom is not I want to see and disable oom will be good. > And as I previous said, we have to solve oom_killer_disabled issue in > do_try_to_free_pages. > > Thanks, Dave. > -- > Kind regards, > Minchan Kim > -- Regards dave -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST] [AUTOTEST][PATCH] Add ability to call autotest client tests from kvm tests like a subtest.
On Tue, Apr 26, 2011 at 01:22:13PM -0400, Cleber Rosa wrote:
> On 04/26/2011 11:52 AM, Lucas Meneghel Rodrigues wrote:
> >On Tue, 2011-04-26 at 23:08 +0800, Amos Kong wrote:
> >>On Tue, Apr 26, 2011 at 12:22:31PM +0200, Jiří Župka wrote:
> >>>+else:
> >>>+logging.error("Host cannot communicate with client by"
> >>>+ " normal network connection.")
> >>>\ No newline at end of file
> >>>diff --git a/client/tests/kvm/tests_base.cfg.sample
> >>>b/client/tests/kvm/tests_base.cfg.sample
> >>>index 5d274f8..f9efb4b 100644
> >>>--- a/client/tests/kvm/tests_base.cfg.sample
> >>>+++ b/client/tests/kvm/tests_base.cfg.sample
> >>>@@ -255,11 +255,19 @@ variants:
> >>> test_control_file = rtc.control
> >>> - iozone:
> >>> test_control_file = iozone.control
> >>>-- flail:
> >>>+ - flail:
> >>A typo? please don't use \t for indentation.
> >^ No, flail is the actual name of this test, a syscall fuzzer, not a
> >typo.
> >
> I guess the typo Amos mentioned (and I also pointed out) is not the
> variant name but the new indentation. Right Amos?
Yes.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] virtio_balloon: disable oom killer when fill balloon
On Tue, Apr 26, 2011 at 6:39 PM, Dave Young wrote: > On Tue, Apr 26, 2011 at 5:28 PM, Minchan Kim wrote: >> Please resend this with [2/2] to linux-mm. >> >> On Tue, Apr 26, 2011 at 5:59 PM, Dave Young >> wrote: >>> When memory pressure is high, virtio ballooning will probably cause oom >>> killing. >>> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it >>> will make memory becoming low then memory alloc of other processes will >>> trigger >>> oom killing. It is not desired behaviour. >> >> I can't understand why it is undesirable. >> Why do we have to handle it specially? >> > > Suppose user run some random memory hogging process while ballooning > it will be undesirable. In VM POV, kvm and random memory hogging processes are customers. If we handle ballooning specially with disable OOM, what happens other processes requires memory at same time? Should they wait for balloon driver to release memory? I don't know your point. Sorry. Could you explain your scenario in detail for justify your idea? And as I previous said, we have to solve oom_killer_disabled issue in do_try_to_free_pages. Thanks, Dave. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Apr 26
On 04/26/2011 11:47 AM, Lucas Meneghel Rodrigues wrote: On Tue, 2011-04-26 at 17:58 +0300, Avi Kivity wrote: On 04/26/2011 05:41 PM, Chris Wright wrote: - having basic common config could be useful Hi Lucas, Could you send your suggested config as a patch to qemu.git? Even better if it was automatically invoked via a make autotest target although if you supply the config, I'll happily patch the Makefile. Regards, Anthony Liguori My config is: --- include tests_base.cfg include cdkeys.cfg image_name(_.*)? ?<= images/ cdrom(_.*)? ?<= isos/ drive_cache=unsafe extra_params = -enable-kvm variants: - @avi: only no_pci_assignable only qcow2 only ide only smp2 only Fedora.9.32 Fedora.9.64 WinVista.64sp1 WinXP ^ Maybe Fedora could be bumped to F14, and WinVista, replaced with Win7 only install setup boot reboot migrate shutdown ^ Instead of the install setup unattended install could be used here... only rtl8139 only smallpages abort_on_error = yes kill_vm.* ?= no kill_unresponsive_vms.* ?= no WinXP.64|Win2003.64: no shutdown no reboot # Choose your test list from the testsets defined only avi pci_assignable = no serial_console = no --- In addition I run the kvm-unit-tests tests. -- 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: [CentOS] Install CentOS as KVM guest
Unfortunately, things still don't work. It's just ridiculous that the installer under KVM does not detect the cdrom drive it was booted from. Trying to do a net-install doesn't work, maybe I messed up the networking even though br0 and eth0 is working on the host. Nevermind, let's install apache and use the mounted ISO. Verified apache is working and the CentOS folder is accessible via web browser. But, still the guest installer cannot seem to access the installation files. OK, so maybe I messed up the networking, after all I am the noob... maybe specifying --network=bridge:br0 isn't enough. There was something about a tap or tunnel when initially reading up on bridged networking. Looking up more on this, there are several resources (sorry KVM FAQ leads to a page that no longer exist) which like many other instructions, give the commands without really explaining what/why. So I have to run some tunctl command and scripts to add a bridge and tunnel/tap... but wait, I already made my bridge, will running the script kill my networking by creating a second bridge? Especially the warning about temporarily loosing connectivity due to ifcfg1 being reset. And if I need to run this script everytime in order to activate the bridge and tunnel, doesn't that mean all my guest OS are screwed if the host reboots while I'm not around? Shouldn't these things go into permanent files like if-tun0 or something? Every year, I get a little closer to not using VMWare but it seems like this year is going to be victory for VMWare again. CC to kvm mailing list but I expect, like my previous request for help to the list, it will be rejected by mailman or a moderator. Just damn frustrated, even if it's probably just me being too stupid to know how to use 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: RCU+KVM: making CPU guest mode a quiescent state.
On Tue, Apr 26, 2011 at 03:38:24PM +0300, Gleb Natapov wrote: > Hello Paul, > > I have a question about RCU + KVM. KVM does not hold any references to RCU > protected data when it switches CPU into a guest mode. In fact switching > to a guest mode is very similar to exiting to userspase from RCU point > of view. In addition CPU may stay in a guest mode for quite a long time > (up to one time slice). It looks like it will be beneficial to treat guest > mode as quiescent state, just like user-mode execution. How can this be > done? I was trying to find how RCU knows about cpu entering user-mode, > but it seems that it does this by checking CPU mode in a timer interrupt > (update_process_times()->rcu_check_callbacks()). This will not work for > guest mode detection since timer interrupt will kick CPU out of a guest > mode and timer interrupt will always see CPU in kernel mode. Do we have > a simple function to call to notify RCU that CPU passed quiescent state > which we can call just before entering guest? Hello, Gleb, You could call rcu_note_context_switch(), passing it the current CPU. Please note that preemption -must- be disabled when calling this. You could call this just after exiting the guest as well as just before entering guest. Longer term, it might be interesting to try Frederic Weisbecker's patch, which disables scheduling-clock interrupts while in user mode if there is only one runnable task on the CPU in question. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Apr 26
On Tue, 2011-04-26 at 17:58 +0300, Avi Kivity wrote: > On 04/26/2011 05:41 PM, Chris Wright wrote: > > - having basic common config could be useful > > > > My config is: > --- > include tests_base.cfg > include cdkeys.cfg > > image_name(_.*)? ?<= images/ > cdrom(_.*)? ?<= isos/ > drive_cache=unsafe > extra_params = -enable-kvm > > variants: > - @avi: > only no_pci_assignable > only qcow2 > only ide > only smp2 > only Fedora.9.32 Fedora.9.64 WinVista.64sp1 WinXP ^ Maybe Fedora could be bumped to F14, and WinVista, replaced with Win7 > only install setup boot reboot migrate shutdown ^ Instead of the install setup unattended install could be used here... > only rtl8139 > only smallpages > > abort_on_error = yes > kill_vm.* ?= no > kill_unresponsive_vms.* ?= no > > WinXP.64|Win2003.64: > no shutdown > no reboot > > # Choose your test list from the testsets defined > only avi > > pci_assignable = no > serial_console = no > --- > > In addition I run the kvm-unit-tests tests. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST] [AUTOTEST][PATCH] Add ability to call autotest client tests from kvm tests like a subtest.
On 04/26/2011 11:52 AM, Lucas Meneghel Rodrigues wrote:
On Tue, 2011-04-26 at 23:08 +0800, Amos Kong wrote:
On Tue, Apr 26, 2011 at 12:22:31PM +0200, Jiří Župka wrote:
+else:
+logging.error("Host cannot communicate with client by"
+ " normal network connection.")
\ No newline at end of file
diff --git a/client/tests/kvm/tests_base.cfg.sample
b/client/tests/kvm/tests_base.cfg.sample
index 5d274f8..f9efb4b 100644
--- a/client/tests/kvm/tests_base.cfg.sample
+++ b/client/tests/kvm/tests_base.cfg.sample
@@ -255,11 +255,19 @@ variants:
test_control_file = rtc.control
- iozone:
test_control_file = iozone.control
-- flail:
+ - flail:
A typo? please don't use \t for indentation.
^ No, flail is the actual name of this test, a syscall fuzzer, not a
typo.
I guess the typo Amos mentioned (and I also pointed out) is not the
variant name but the new indentation. Right Amos?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] KVM: MMU: Optimize guest page table walk
On 04/26/2011 07:26 PM, Takuya Yoshikawa wrote: On Tue, 26 Apr 2011 17:54:24 +0300 Avi Kivity wrote: > Please post a simple patch that uses two get_user()s for that case > (64-bit pte on 32-bit host). Then work with the x86 tree to see if > they'll accept 64-bit get_user(), and once they do, we can go back to a > simple get_user() again. > I made a patch which seems to reflect what you said! If this kind of fix is OK with you, I'll test on both x86_32 and x86_64, and send the patch with some changelog tomorrow. Yes, that looks right. -- 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 1/1 v2] KVM: MMU: Optimize guest page table walk
On 04/26/2011 06:13 PM, Takuya Yoshikawa wrote: > Please post a simple patch that uses two get_user()s for that case > (64-bit pte on 32-bit host). Then work with the x86 tree to see if > they'll accept 64-bit get_user(), and once they do, we can go back to a > simple get_user() again. > > btw, I think we can use __get_user() here since the address must have > been already validated. Yes, I thought that at first. But don't we need to care KVM's address translation bugs? It's a pity to do a runtime check when we can do a setup time check instead. So let's review the setup code and then use __get_user(). -- 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 v3 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
On Tue, Apr 26, 2011 at 07:06:34PM +0200, Jan Kiszka wrote:
> On 2011-04-26 18:06, Christoph Hellwig wrote:
> > On Tue, Apr 26, 2011 at 04:01:00PM +0200, Jan Kiszka wrote:
> >> +static bool modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
> >> +{
> >> +return (old ^ new) & mask;
> >> +}
> >> +
> >
> > A more usual name would be toggle_bit. But you're passing in a mask
> > to be modified, so it would be more a toggle_bits or toggle_mask.
> >
>
> This function is checking for a change. But I've no problem renaming it
> to toggling_bit or so if that's preferred.
Err, you're right, I read it as doing a ^=. So keeping your naming
scheme sounds fine.
--
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 v3 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
On 2011-04-26 18:06, Christoph Hellwig wrote:
> On Tue, Apr 26, 2011 at 04:01:00PM +0200, Jan Kiszka wrote:
>> +static bool modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
>> +{
>> +return (old ^ new) & mask;
>> +}
>> +
>
> A more usual name would be toggle_bit. But you're passing in a mask
> to be modified, so it would be more a toggle_bits or toggle_mask.
>
This function is checking for a change. But I've no problem renaming it
to toggling_bit or so if that's preferred.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix long-standing crash in 32bit migration
This change fixes a long-standing immediate crash (memory corruption
and abort in glibc malloc code) in migration on 32bits.
The bug is present since this commit:
commit 692d9aca97b865b0f7903565274a52606910f129
Author: Bruce Rogers
Date: Wed Sep 23 16:13:18 2009 -0600
qemu-kvm: allocate correct size for dirty bitmap
The dirty bitmap copied out to userspace is stored in a long array,
and gets copied out to userspace accordingly. This patch accounts
for that correctly. Currently I'm seeing kvm crashing due to writing
beyond the end of the alloc'd dirty bitmap memory, because the buffer
has the wrong size.
Signed-off-by: Bruce Rogers
Signed-off-by: Marcelo Tosatti
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ int kvm_get_dirty_pages_range(kvm_context_t kvm, unsigned long phys_addr,
-buf = qemu_malloc((slots[i].len / 4096 + 7) / 8 + 2);
+buf = qemu_malloc(BITMAP_SIZE(slots[i].len));
r = kvm_get_map(kvm, KVM_GET_DIRTY_LOG, i, buf);
BITMAP_SIZE is now open-coded in that function, like this:
size = ALIGN(((mem->memory_size) >> TARGET_PAGE_BITS), HOST_LONG_BITS) / 8;
The problem is that HOST_LONG_BITS in 32bit userspace is 32
but it's 64 in 64bit kernel. So userspace aligns this to
32, and kernel to 64, but since no length is passed from
userspace to kernel on ioctl, kernel uses its size calculation
and copies 4 extra bytes to userspace, corrupting memory.
Here's how it looks like during migrate execution:
our=20, kern=24
our=4, kern=8
...
our=4, kern=8
our=4064, kern=4064
our=512, kern=512
our=4, kern=8
our=20, kern=24
our=4, kern=8
...
our=4, kern=8
our=4064, kern=4064
*** glibc detected *** ./x86_64-softmmu/qemu-system-x86_64: realloc(): invalid
next size: 0x08f20528 ***
(our is userspace size above, kern is the size as calculated
by the kernel).
Fix this by always aligning to 64 in a hope that no platform will
have sizeof(long)>8 any time soon, and add a comment describing it
all. It's a small price to pay for bad kernel design.
Alternatively it's possible to fix that in the kernel by using
different size calculation depending on the current process.
But this becomes quite ugly.
Special thanks goes to Stefan Hajnoczi for spotting the fundamental
cause of the issue, and to Alexander Graf for his support in #qemu.
Signed-off-by: Michael Tokarev
CC: Bruce Rogers
---
kvm-all.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 7e407f0..3e75e9e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -382,7 +382,19 @@ static int
kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
break;
}
-size = ALIGN(((mem->memory_size) >> TARGET_PAGE_BITS), HOST_LONG_BITS)
/ 8;
+ /* XXX bad kernel interface alert
+ * For dirty bitmap, kernel allocates array of size aligned to
+ * bits-per-long. But for case when the kernel is 64bits and
+ * the userspace is 32bits, userspace can't align to the same
+ * bits-per-long, since sizeof(long) is different between kernel
+ * and user space. This way, userspace will provide buffer which
+ * may be 4 bytes less than the kernel will use, resulting in
+ * userspace memory corruption (which is not detectable by valgrind
+ * too, in most cases).
+ * So for now, let's align to 64 instead of HOST_LONG_BITS here, in
+ * a hope that sizeof(long) wont become >8 any time soon.
+ */
+size = ALIGN(((mem->memory_size) >> TARGET_PAGE_BITS),
/*HOST_LONG_BITS*/ 64) / 8;
if (!d.dirty_bitmap) {
d.dirty_bitmap = qemu_malloc(size);
} else if (size > allocated_size) {
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] KVM: MMU: Optimize guest page table walk
On Tue, 26 Apr 2011 17:54:24 +0300
Avi Kivity wrote:
> Please post a simple patch that uses two get_user()s for that case
> (64-bit pte on 32-bit host). Then work with the x86 tree to see if
> they'll accept 64-bit get_user(), and once they do, we can go back to a
> simple get_user() again.
>
I made a patch which seems to reflect what you said!
If this kind of fix is OK with you, I'll test on both x86_32 and x86_64,
and send the patch with some changelog tomorrow.
Thanks,
Takuya
---
arch/x86/kvm/paging_tmpl.h | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index a32a1c8..1e44969 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -115,6 +115,20 @@ static unsigned FNAME(gpte_access)(struct kvm_vcpu *vcpu,
pt_element_t gpte)
return access;
}
+static int FNAME(read_gpte)(pt_element_t *pte, pt_element_t __user *ptep_user)
+{
+#if defined(CONFIG_X86_32) && (PTTYPE == 64)
+ u32 *p = (u32 *)pte;
+ u32 __user *p_user = (u32 __user *)ptep_user;
+
+ if (get_user(*p, p_user))
+ return -EFAULT;
+ return get_user(*(p + 1), p_user + 1);
+#else
+ return get_user(*pte, ptep_user);
+#endif
+}
+
/*
* Fetch a guest pte for a guest virtual address
*/
@@ -185,7 +199,7 @@ walk:
}
ptep_user = (pt_element_t __user *)((void *)host_addr + offset);
- if (get_user(pte, ptep_user)) {
+ if (FNAME(read_gpte)(&pte, ptep_user)) {
present = false;
break;
}
--
1.7.1
--
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 v3 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
On Tue, Apr 26, 2011 at 04:01:00PM +0200, Jan Kiszka wrote:
> +static bool modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
> +{
> +return (old ^ new) & mask;
> +}
> +
A more usual name would be toggle_bit. But you're passing in a mask
to be modified, so it would be more a toggle_bits or toggle_mask.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AUTOTEST][PATCH] Add ability to call autotest client tests from kvm tests like a subtest.
On Tue, 2011-04-26 at 23:08 +0800, Amos Kong wrote:
> On Tue, Apr 26, 2011 at 12:22:31PM +0200, Jiří Župka wrote:
> > +else:
> > +logging.error("Host cannot communicate with client by"
> > + " normal network connection.")
> > \ No newline at end of file
> > diff --git a/client/tests/kvm/tests_base.cfg.sample
> > b/client/tests/kvm/tests_base.cfg.sample
> > index 5d274f8..f9efb4b 100644
> > --- a/client/tests/kvm/tests_base.cfg.sample
> > +++ b/client/tests/kvm/tests_base.cfg.sample
> > @@ -255,11 +255,19 @@ variants:
> > test_control_file = rtc.control
> > - iozone:
> > test_control_file = iozone.control
> > -- flail:
> > + - flail:
>
> A typo? please don't use \t for indentation.
^ No, flail is the actual name of this test, a syscall fuzzer, not a
typo.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] KVM: MMU: Optimize guest page table walk
> Please post a simple patch that uses two get_user()s for that case > (64-bit pte on 32-bit host). Then work with the x86 tree to see if > they'll accept 64-bit get_user(), and once they do, we can go back to a > simple get_user() again. > > btw, I think we can use __get_user() here since the address must have > been already validated. Yes, I thought that at first. But don't we need to care KVM's address translation bugs? Takuya -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AUTOTEST][PATCH] Add ability to call autotest client tests from kvm tests like a subtest.
On Tue, Apr 26, 2011 at 12:22:31PM +0200, Jiří Župka wrote:
> Example run autotest/client/netperf2 like a server.
>
> test.runsubtest("netperf2", tag="server", server_ip=host_ip,
> client_ip=guest_ip, role='server')
>
> Client part is called in paralel thread on virtual machine.
>
> guest = kvm_utils.Thread(kvm_test_utils.run_autotest,
> (vm, session, control_path, control_args,
> timeout, outputdir, params))
> guest.start()
>
> On the guest is required to have installed the program mpstat for netpert2
> test.
> Netperf2 test will be changed or will be created in new version.
>
> This patch are necessary to avoid of creation double version of test.
> netperf, multicast, etc..
It's cool!
> Signed-off-by: Jiří Župka
> ---
> client/bin/client_logging_config.py|5 +-
> client/bin/net/net_utils.py| 16 -
> client/common_lib/base_job.py |2 +
> client/common_lib/logging_config.py|3 +-
> client/common_lib/test.py | 21 ++-
> client/tests/kvm/html_report.py| 115
> ++--
> client/tests/kvm/kvm_test_utils.py | 19 --
> client/tests/kvm/tests/subtest.py | 43
> client/tests/kvm/tests_base.cfg.sample | 10 +++-
> client/tests/netperf2/netperf2.py |3 +-
> 10 files changed, 173 insertions(+), 64 deletions(-)
> create mode 100644 client/tests/kvm/tests/subtest.py
>
> diff --git a/client/bin/client_logging_config.py
> b/client/bin/client_logging_config.py
> index a59b078..28c007d 100644
> --- a/client/bin/client_logging_config.py
> +++ b/client/bin/client_logging_config.py
> @@ -12,8 +12,9 @@ class ClientLoggingConfig(logging_config.LoggingConfig):
>
>
> def configure_logging(self, results_dir=None, verbose=False):
> -super(ClientLoggingConfig, self).configure_logging(use_console=True,
> - verbose=verbose)
> +super(ClientLoggingConfig, self).configure_logging(
> +
> use_console=self.use_console,
> + verbose=verbose)
>
> if results_dir:
> log_dir = os.path.join(results_dir, 'debug')
> diff --git a/client/bin/net/net_utils.py b/client/bin/net/net_utils.py
> index 868958c..ac9b494 100644
> --- a/client/bin/net/net_utils.py
> +++ b/client/bin/net/net_utils.py
> @@ -5,7 +5,7 @@ This library is to release in the public repository.
>
> import commands, os, re, socket, sys, time, struct
> from autotest_lib.client.common_lib import error
> -import utils
> +from autotest_lib.client.common_lib import utils
>
> TIMEOUT = 10 # Used for socket timeout and barrier timeout
>
> @@ -27,6 +27,20 @@ class network_utils(object):
> utils.system('/sbin/ifconfig -a')
>
>
> +def get_corespond_local_ip(self, query_ip, netmask="24"):
> +"""
> +Get ip address in local system which can communicate with quert_ip.
> +
> +@param query_ip: IP of client which want communicate with autotest
> machine.
> +@return: IP address which can communicate with query_ip
> +"""
> +ip = utils.system_output("ip addr show to %s/%s" % (query_ip,
> netmask))
> +ip = re.search(r"inet ([0-9.]*)/",ip)
> +if ip is None:
> +return ip
> +return ip.group(1)
> +
> +
> def disable_ip_local_loopback(self, ignore_status=False):
> utils.system("echo '1' > /proc/sys/net/ipv4/route/no_local_loopback",
> ignore_status=ignore_status)
> diff --git a/client/common_lib/base_job.py b/client/common_lib/base_job.py
> index 843c0e8..eef9efc 100644
> --- a/client/common_lib/base_job.py
> +++ b/client/common_lib/base_job.py
> @@ -1117,6 +1117,7 @@ class base_job(object):
> tag_parts = []
>
> # build up the parts of the tag used for the test name
> +master_testpath = dargs.get('master_testpath', "")
> base_tag = dargs.pop('tag', None)
> if base_tag:
> tag_parts.append(str(base_tag))
> @@ -1132,6 +1133,7 @@ class base_job(object):
> if subdir_tag:
> tag_parts.append(subdir_tag)
> subdir = '.'.join([testname] + tag_parts)
> +subdir = os.path.join(master_testpath, subdir)
> tag = '.'.join(tag_parts)
>
> return full_testname, subdir, tag
> diff --git a/client/common_lib/logging_config.py
> b/client/common_lib/logging_config.py
> index afe754a..9114d7a 100644
> --- a/client/common_lib/logging_config.py
> +++ b/client/common_lib/logging_config.py
> @@ -32,9 +32,10 @@ class LoggingConfig(object):
> fmt='%(asctime)s %(levelname)-5.5s| %(message)s',
> datefmt='%H:%M:%S')
>
> -def __init__(self):
> +def __init__(self, use_console=True):
> self.logger = logging.getLogger()
> s
Re: KVM call minutes for Apr 26
On 04/26/2011 05:41 PM, Chris Wright wrote: - having basic common config could be useful My config is: --- include tests_base.cfg include cdkeys.cfg image_name(_.*)? ?<= images/ cdrom(_.*)? ?<= isos/ drive_cache=unsafe extra_params = -enable-kvm variants: - @avi: only no_pci_assignable only qcow2 only ide only smp2 only Fedora.9.32 Fedora.9.64 WinVista.64sp1 WinXP only install setup boot reboot migrate shutdown only rtl8139 only smallpages abort_on_error = yes kill_vm.* ?= no kill_unresponsive_vms.* ?= no WinXP.64|Win2003.64: no shutdown no reboot # Choose your test list from the testsets defined only avi pci_assignable = no serial_console = no --- In addition I run the kvm-unit-tests tests. -- 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 1/1 v2] KVM: MMU: Optimize guest page table walk
On 04/26/2011 05:40 PM, Takuya Yoshikawa wrote: On Tue, 26 Apr 2011 08:34:57 +0200 Jan Kiszka wrote: > > Google said that there was a similar talk on LKML in 2004. > > > > On that threads, Linus explained how to tackle on the 64-bit get_user > > implementation. But I could not see what happened after that. > > Mmh, maybe the kernel was lacking a real use case, so no one seriously > cared. > > I don't see a fundamental blocker for an x86-32 __get_user_8 version > based on two mov. I would give it a try. > > Jan > Thank you! Avi, do we revert the patch now, or ...? Please post a simple patch that uses two get_user()s for that case (64-bit pte on 32-bit host). Then work with the x86 tree to see if they'll accept 64-bit get_user(), and once they do, we can go back to a simple get_user() again. btw, I think we can use __get_user() here since the address must have been already validated. -- 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 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
On 2011-04-26 16:24, "大村 圭" wrote: > > 2011/4/25 Jan Kiszka : >> On 2011-04-25 13:00, OHMURA Kei wrote: >>> From: Yoshiaki Tamura >>> >>> Record mmio write event to replay it upon failover. >>> >>> Signed-off-by: Yoshiaki Tamura >>> Signed-off-by: OHMURA Kei >>> --- >>> exec.c |4 >>> 1 files changed, 4 insertions(+), 0 deletions(-) >>> >>> diff --git a/exec.c b/exec.c >>> index c3dc68a..3c3cece 100644 >>> --- a/exec.c >>> +++ b/exec.c >>> @@ -33,6 +33,7 @@ >>> #include "osdep.h" >>> #include "kvm.h" >>> #include "qemu-timer.h" >>> +#include "event-tap.h" >>> #if defined(CONFIG_USER_ONLY) >>> #include >>> #include >>> @@ -3736,6 +3737,9 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, >>> uint8_t *buf, >>> io_index = (pd >> IO_MEM_SHIFT) & (IO_MEM_NB_ENTRIES - 1); >>> if (p) >>> addr1 = (addr & ~TARGET_PAGE_MASK) + p->region_offset; >>> + >>> +event_tap_mmio(addr, buf, len); >>> + >> >> You know that this is incomplete? A few devices are calling st*_phys >> directly, specifically virtio. >> >> What kind of mmio should be traced here, device or CPU originated? Or both? >> >> Jan >> >> > > To let Kemari replay outputs upon failover, tracing CPU originated > mmio (specifically write requests) should be enough. > IIUC, we can reproduce device originated mmio as a result of cpu > originated mmio. > OK, I see. But this tap will only work for KVM. I think you either have to catch the other paths that TCG could take as well or maybe better move the hook into kvm-all - then it's absolutely clear that this is no generic feature. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM call minutes for Apr 26
Tools for resource accounting the virtual machines. - Luis Castro was not on the call Status of glib tree - next steps? - full conversion done in tree - still targeting 0.15 status of QCFG - code generator rewritten to be more generic and useful - merge core infrastructure first - to not block other work waiting on full conversion - still need to complete full conversion qemu-kvm merge - status - review and merge/feedback pending from Avi on current outstanding patches - still have some 60 patches - break them into a few smaller series - next steps, specifically: - upstreaming in-kernel irqchip support - MSI/MSI-X (cleanup and make mergable) - this is a decent amount of work, Jan is solo...anyone want to help? - need to be careful of regressions - add tests to avi's autotest run (e.g., cpu hotplug) - cpu hotplug test initiated from host side - online needs some cooperation in linux - still unclear on what's supported, windows apparently only supports online autotest - had autotest test day, feedback coming on list - some issues with getting set up - having basic common config could be useful KVM Forum reminder - send in your proposals -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] KVM: MMU: Optimize guest page table walk
On Tue, 26 Apr 2011 08:34:57 +0200 Jan Kiszka wrote: > > Google said that there was a similar talk on LKML in 2004. > > > > On that threads, Linus explained how to tackle on the 64-bit get_user > > implementation. But I could not see what happened after that. > > Mmh, maybe the kernel was lacking a real use case, so no one seriously > cared. > > I don't see a fundamental blocker for an x86-32 __get_user_8 version > based on two mov. I would give it a try. > > Jan > Thank you! Avi, do we revert the patch now, or ...? Takuya -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for April 26th
On 04/26/11 15:09, Anthony Liguori wrote: > On 04/26/2011 06:47 AM, Jes Sorensen wrote: >> On 04/26/11 11:24, Juan Quintela wrote: >>> >>> Please, send in any agenda items you are interested in covering. >>> >>> From last week: >>> Tools for resource accounting the virtual machines. >>> Luis Antonio Galindo Castro (FunkyM0nk3y) >>> >> >> - Status of glib tree - next steps? > > I actually decided to just rewriting all of QEMU in Python and C++.. > You'll have to compete with my Java port! -- 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 v3 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
Just like PCI devices, the HPET requires special care to route MSI
events to the in-kernel irqchip if enabled.
Signed-off-by: Jan Kiszka
---
hw/hpet.c | 71 -
1 files changed, 70 insertions(+), 1 deletions(-)
v3: Let modifying_bit return bool to avoid unexpected results.
diff --git a/hw/hpet.c b/hw/hpet.c
index 6ce07bc..ed8018d 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -31,6 +31,7 @@
#include "hpet_emul.h"
#include "sysbus.h"
#include "mc146818rtc.h"
+#include "kvm.h"
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -55,6 +56,7 @@ typedef struct HPETTimer { /* timers */
uint8_t wrap_flag; /* timer pop will indicate wrap for one-shot 32-bit
* mode. Next pop will be actual timer expiration.
*/
+KVMMsiMessage kmm;
} HPETTimer;
typedef struct HPETState {
@@ -141,11 +143,59 @@ static int deactivating_bit(uint64_t old, uint64_t new,
uint64_t mask)
return ((old & mask) && !(new & mask));
}
+static bool modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
+{
+return (old ^ new) & mask;
+}
+
static uint64_t hpet_get_ticks(HPETState *s)
{
return ns_to_ticks(qemu_get_clock_ns(vm_clock) + s->hpet_offset);
}
+static void kvm_hpet_msi_update(HPETTimer *t)
+{
+KVMMsiMessage new_entry;
+int ret = 0;
+
+if (!kvm_enabled() || !kvm_irqchip_in_kernel()) {
+return;
+}
+
+if (timer_fsb_route(t)) {
+new_entry.addr_hi = 0;
+new_entry.addr_lo = t->fsb >> 32;
+new_entry.data = t->fsb & 0x;
+if (t->kmm.gsi == -1) {
+kvm_msi_message_add(&new_entry);
+ret = 1;
+} else {
+ret = kvm_msi_message_update(&t->kmm, &new_entry);
+}
+if (ret > 0) {
+t->kmm = new_entry;
+kvm_commit_irq_routes();
+}
+} else if (t->kmm.gsi != -1) {
+kvm_msi_message_del(&t->kmm);
+t->kmm.gsi = -1;
+}
+}
+
+static void kvm_hpet_msi_free(HPETState *s)
+{
+int i;
+
+for (i = 0; i < s->num_timers; i++) {
+HPETTimer *timer = &s->timer[i];
+
+if (timer->kmm.gsi != -1) {
+kvm_msi_message_del(&timer->kmm);
+timer->kmm.gsi = -1;
+}
+}
+}
+
/*
* calculate diff between comparator value and current ticks
*/
@@ -192,7 +242,11 @@ static void update_irq(struct HPETTimer *timer, int set)
qemu_irq_lower(s->irqs[route]);
}
} else if (timer_fsb_route(timer)) {
-stl_phys(timer->fsb >> 32, timer->fsb & 0x);
+if (kvm_enabled() && kvm_irqchip_in_kernel()) {
+kvm_set_irq(timer->kmm.gsi, 1, NULL);
+} else {
+stl_phys(timer->fsb >> 32, timer->fsb & 0x);
+}
} else if (timer->config & HPET_TN_TYPE_LEVEL) {
s->isr |= mask;
qemu_irq_raise(s->irqs[route]);
@@ -214,6 +268,8 @@ static int hpet_pre_load(void *opaque)
{
HPETState *s = opaque;
+kvm_hpet_msi_free(s);
+
/* version 1 only supports 3, later versions will load the actual value */
s->num_timers = HPET_MIN_TIMERS;
return 0;
@@ -222,6 +278,7 @@ static int hpet_pre_load(void *opaque)
static int hpet_post_load(void *opaque, int version_id)
{
HPETState *s = opaque;
+int i;
/* Recalculate the offset between the main counter and guest time */
s->hpet_offset = ticks_to_ns(s->hpet_counter) -
qemu_get_clock_ns(vm_clock);
@@ -241,6 +298,10 @@ static int hpet_post_load(void *opaque, int version_id)
hpet_pit_disable();
}
+for (i = 0; i < s->num_timers; i++) {
+kvm_hpet_msi_update(&s->timer[i]);
+}
+
return 0;
}
@@ -485,6 +546,9 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
} else if (deactivating_bit(old_val, new_val, HPET_TN_ENABLE)) {
hpet_del_timer(timer);
}
+if (modifying_bit(old_val, new_val, HPET_TN_FSB_ENABLE)) {
+kvm_hpet_msi_update(timer);
+}
break;
case HPET_TN_CFG + 4: // Interrupt capabilities
DPRINTF("qemu: invalid HPET_TN_CFG+4 write\n");
@@ -533,9 +597,11 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
break;
case HPET_TN_ROUTE:
timer->fsb = (timer->fsb & 0xULL) | new_val;
+kvm_hpet_msi_update(timer);
break;
case HPET_TN_ROUTE + 4:
timer->fsb = (new_val << 32) | (timer->fsb & 0x);
+kvm_hpet_msi_update(timer);
break;
default:
DPRINTF("qemu: invalid hpet_ram_writel\n");
@@ -667,6 +733,8 @@ static void hpet_reset(DeviceState *d)
hpet_cfg.hpet[s->hpet_id].event_timer_block_id = (uint32_t)s->capability;
hpet_cfg.hpet[s->hpet_id].address = sysbus_from_qdev(d)->mmio[0].addr;
count = 1;
+
+
Re: [PATCH v2 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
On 2011-04-26 15:56, Avi Kivity wrote:
> On 04/26/2011 04:55 PM, Jan Kiszka wrote:
>> On 2011-04-26 15:30, Michael Tokarev wrote:
>>> 26.04.2011 17:19, Jan Kiszka wrote:
>>>
hw/hpet.c | 71
-
>>>
+static int modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
+{
+return (old ^ new)& mask;
+}
>>>
>>> Such constructs always look suspicious. I'm not even sure anymore
>>> (after using C for over 20 years ;) that this works... how about
>>>
>>> return (old ^ new)& mask ? 1 : 0;
>>>
>>> instead, or something along this? I mean, if sizeof(int)==4, how
>>> `return 1ULL<<32' will be interpreted in this context? Tiny test
>>> program tells me it will return 0...
>>
>> Good catch, will fix (doesn't bite use here, flags fit into 32 bit, but
>> nevertheless).
>>
>
> Note, a bool return type works here.
Yes, that was my favorite as well.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
On 04/26/2011 04:55 PM, Jan Kiszka wrote:
On 2011-04-26 15:30, Michael Tokarev wrote:
> 26.04.2011 17:19, Jan Kiszka wrote:
>
>> hw/hpet.c | 71
-
>
>> +static int modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
>> +{
>> +return (old ^ new)& mask;
>> +}
>
> Such constructs always look suspicious. I'm not even sure anymore
> (after using C for over 20 years ;) that this works... how about
>
> return (old ^ new)& mask ? 1 : 0;
>
> instead, or something along this? I mean, if sizeof(int)==4, how
> `return 1ULL<<32' will be interpreted in this context? Tiny test
> program tells me it will return 0...
Good catch, will fix (doesn't bite use here, flags fit into 32 bit, but
nevertheless).
Note, a bool return type works here.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
On 2011-04-26 15:30, Michael Tokarev wrote:
> 26.04.2011 17:19, Jan Kiszka wrote:
>
>> hw/hpet.c | 71
>> -
>
>> +static int modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
>> +{
>> +return (old ^ new) & mask;
>> +}
>
> Such constructs always look suspicious. I'm not even sure anymore
> (after using C for over 20 years ;) that this works... how about
>
> return (old ^ new) & mask ? 1 : 0;
>
> instead, or something along this? I mean, if sizeof(int)==4, how
> `return 1ULL<<32' will be interpreted in this context? Tiny test
> program tells me it will return 0...
Good catch, will fix (doesn't bite use here, flags fit into 32 bit, but
nevertheless).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
26.04.2011 17:19, Jan Kiszka wrote:
> hw/hpet.c | 71
> -
> +static int modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
> +{
> +return (old ^ new) & mask;
> +}
Such constructs always look suspicious. I'm not even sure anymore
(after using C for over 20 years ;) that this works... how about
return (old ^ new) & mask ? 1 : 0;
instead, or something along this? I mean, if sizeof(int)==4, how
`return 1ULL<<32' will be interpreted in this context? Tiny test
program tells me it will return 0...
/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command
On 04/26/2011 08:26 AM, Luiz Capitulino wrote: On Thu, 21 Apr 2011 11:23:54 +0800 Lai Jiangshan wrote: Hi, Anthony Liguori Any suggestion? Although all command line interfaces will be converted to to use QMP interfaces in 0.16, I hope inject-nmi come into QAPI earlier, 0.15. I don't know what Anthony thinks about adding new commands like this one that early to the new QMP interface, but adding them to current QMP will certainly cause less code churn on your side. That's what I'd recommend for now. Yeah, sorry, this whole series has been confused in the QAPI discussion. I did not intend for QAPI to be disruptive to current development. As far as I can tell, the last series that was posted (before the QAPI post) still had checkpatch.pl issues (scripts/checkpatch.pl btw) and we had agreed that once that was resolved, it would come in through Luiz's tree. 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: [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command
On Thu, 21 Apr 2011 11:23:54 +0800 Lai Jiangshan wrote: > > Hi, Anthony Liguori > > Any suggestion? > > Although all command line interfaces will be converted to to use QMP > interfaces in 0.16, > I hope inject-nmi come into QAPI earlier, 0.15. I don't know what Anthony thinks about adding new commands like this one that early to the new QMP interface, but adding them to current QMP will certainly cause less code churn on your side. That's what I'd recommend for now. -- 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 v2 7/9] qemu-kvm: Add in-kernel irqchip support for MSI
This adds the required bits to map classic MSI vectors on KVM IRQ
routing entries and deliver them via the irqchip if enabled.
Signed-off-by: Jan Kiszka
---
hw/msi.c | 111 ++
hw/pci.h |4 ++
2 files changed, 115 insertions(+), 0 deletions(-)
diff --git a/hw/msi.c b/hw/msi.c
index 3dc3a24..18f683b 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -20,6 +20,7 @@
#include "msi.h"
#include "range.h"
+#include "kvm.h"
/* Eventually those constants should go to Linux pci_regs.h */
#define PCI_MSI_PENDING_32 0x10
@@ -109,6 +110,92 @@ bool msi_enabled(const PCIDevice *dev)
PCI_MSI_FLAGS_ENABLE);
}
+static void kvm_msi_message_from_vector(PCIDevice *dev, unsigned vector,
+KVMMsiMessage *kmm)
+{
+uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
+bool msi64bit = flags & PCI_MSI_FLAGS_64BIT;
+unsigned int nr_vectors = msi_nr_vectors(flags);
+
+kmm->addr_lo = pci_get_long(dev->config + msi_address_lo_off(dev));
+if (msi64bit) {
+kmm->addr_hi = pci_get_long(dev->config + msi_address_hi_off(dev));
+} else {
+kmm->addr_hi = 0;
+}
+
+kmm->data = pci_get_word(dev->config + msi_data_off(dev, msi64bit));
+if (nr_vectors > 1) {
+kmm->data &= ~(nr_vectors - 1);
+kmm->data |= vector;
+}
+}
+
+static void kvm_msi_update(PCIDevice *dev)
+{
+uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
+unsigned int nr_vectors = msi_nr_vectors(flags);
+KVMMsiMessage new_entry, *entry;
+bool changed = false;
+unsigned int vector;
+int r;
+
+for (vector = 0; vector < 32; vector++) {
+entry = dev->msi_irq_entries + vector;
+
+if (vector >= nr_vectors) {
+if (vector < dev->msi_entries_nr) {
+kvm_msi_message_del(entry);
+changed = true;
+}
+} else if (vector >= dev->msi_entries_nr) {
+kvm_msi_message_from_vector(dev, vector, entry);
+r = kvm_msi_message_add(entry);
+if (r) {
+fprintf(stderr, "%s: kvm_msi_add failed: %s\n", __func__,
+strerror(-r));
+exit(1);
+}
+changed = true;
+} else {
+kvm_msi_message_from_vector(dev, vector, &new_entry);
+r = kvm_msi_message_update(entry, &new_entry);
+if (r < 0) {
+fprintf(stderr, "%s: kvm_update_msi failed: %s\n",
+__func__, strerror(-r));
+exit(1);
+}
+if (r > 0) {
+*entry = new_entry;
+changed = true;
+}
+}
+}
+dev->msi_entries_nr = nr_vectors;
+if (changed) {
+r = kvm_commit_irq_routes();
+if (r) {
+fprintf(stderr, "%s: kvm_commit_irq_routes failed: %s\n", __func__,
+strerror(-r));
+exit(1);
+}
+}
+}
+
+/* KVM specific MSI helpers */
+static void kvm_msi_free(PCIDevice *dev)
+{
+unsigned int vector;
+
+for (vector = 0; vector < dev->msi_entries_nr; ++vector) {
+kvm_msi_message_del(&dev->msi_irq_entries[vector]);
+}
+if (dev->msi_entries_nr > 0) {
+kvm_commit_irq_routes();
+}
+dev->msi_entries_nr = 0;
+}
+
int msi_init(struct PCIDevice *dev, uint8_t offset,
unsigned int nr_vectors, bool msi64bit, bool msi_per_vector_mask)
{
@@ -159,6 +246,12 @@ int msi_init(struct PCIDevice *dev, uint8_t offset,
pci_set_long(dev->wmask + msi_mask_off(dev, msi64bit),
0x >> (PCI_MSI_VECTORS_MAX - nr_vectors));
}
+
+if (kvm_enabled() && kvm_irqchip_in_kernel()) {
+dev->msi_irq_entries = qemu_malloc(nr_vectors *
+ sizeof(*dev->msix_irq_entries));
+}
+
return config_offset;
}
@@ -166,6 +259,11 @@ void msi_uninit(struct PCIDevice *dev)
{
uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
uint8_t cap_size = msi_cap_sizeof(flags);
+
+if (kvm_enabled() && kvm_irqchip_in_kernel()) {
+kvm_msi_free(dev);
+qemu_free(dev->msi_irq_entries);
+}
pci_del_capability(dev, PCI_CAP_ID_MSIX, cap_size);
MSI_DEV_PRINTF(dev, "uninit\n");
}
@@ -175,6 +273,10 @@ void msi_reset(PCIDevice *dev)
uint16_t flags;
bool msi64bit;
+if (kvm_enabled() && kvm_irqchip_in_kernel()) {
+kvm_msi_free(dev);
+}
+
flags = pci_get_word(dev->config + msi_flags_off(dev));
flags &= ~(PCI_MSI_FLAGS_QSIZE | PCI_MSI_FLAGS_ENABLE);
msi64bit = flags & PCI_MSI_FLAGS_64BIT;
@@ -224,6 +326,11 @@ void msi_notify(PCIDevice *dev, unsigned int vector)
return;
}
+if (kvm_enabled() && kvm_irqchip_in_kernel()) {
+kvm_set_irq(dev->msi_irq_entries[vector].gsi, 1, NULL);
+return;
+}
+
[PATCH v2 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
Just like PCI devices, the HPET requires special care to route MSI
events to the in-kernel irqchip if enabled.
Signed-off-by: Jan Kiszka
---
hw/hpet.c | 71 -
1 files changed, 70 insertions(+), 1 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 6ce07bc..e773ed8 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -31,6 +31,7 @@
#include "hpet_emul.h"
#include "sysbus.h"
#include "mc146818rtc.h"
+#include "kvm.h"
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -55,6 +56,7 @@ typedef struct HPETTimer { /* timers */
uint8_t wrap_flag; /* timer pop will indicate wrap for one-shot 32-bit
* mode. Next pop will be actual timer expiration.
*/
+KVMMsiMessage kmm;
} HPETTimer;
typedef struct HPETState {
@@ -141,11 +143,59 @@ static int deactivating_bit(uint64_t old, uint64_t new,
uint64_t mask)
return ((old & mask) && !(new & mask));
}
+static int modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
+{
+return (old ^ new) & mask;
+}
+
static uint64_t hpet_get_ticks(HPETState *s)
{
return ns_to_ticks(qemu_get_clock_ns(vm_clock) + s->hpet_offset);
}
+static void kvm_hpet_msi_update(HPETTimer *t)
+{
+KVMMsiMessage new_entry;
+int ret = 0;
+
+if (!kvm_enabled() || !kvm_irqchip_in_kernel()) {
+return;
+}
+
+if (timer_fsb_route(t)) {
+new_entry.addr_hi = 0;
+new_entry.addr_lo = t->fsb >> 32;
+new_entry.data = t->fsb & 0x;
+if (t->kmm.gsi == -1) {
+kvm_msi_message_add(&new_entry);
+ret = 1;
+} else {
+ret = kvm_msi_message_update(&t->kmm, &new_entry);
+}
+if (ret > 0) {
+t->kmm = new_entry;
+kvm_commit_irq_routes();
+}
+} else if (t->kmm.gsi != -1) {
+kvm_msi_message_del(&t->kmm);
+t->kmm.gsi = -1;
+}
+}
+
+static void kvm_hpet_msi_free(HPETState *s)
+{
+int i;
+
+for (i = 0; i < s->num_timers; i++) {
+HPETTimer *timer = &s->timer[i];
+
+if (timer->kmm.gsi != -1) {
+kvm_msi_message_del(&timer->kmm);
+timer->kmm.gsi = -1;
+}
+}
+}
+
/*
* calculate diff between comparator value and current ticks
*/
@@ -192,7 +242,11 @@ static void update_irq(struct HPETTimer *timer, int set)
qemu_irq_lower(s->irqs[route]);
}
} else if (timer_fsb_route(timer)) {
-stl_phys(timer->fsb >> 32, timer->fsb & 0x);
+if (kvm_enabled() && kvm_irqchip_in_kernel()) {
+kvm_set_irq(timer->kmm.gsi, 1, NULL);
+} else {
+stl_phys(timer->fsb >> 32, timer->fsb & 0x);
+}
} else if (timer->config & HPET_TN_TYPE_LEVEL) {
s->isr |= mask;
qemu_irq_raise(s->irqs[route]);
@@ -214,6 +268,8 @@ static int hpet_pre_load(void *opaque)
{
HPETState *s = opaque;
+kvm_hpet_msi_free(s);
+
/* version 1 only supports 3, later versions will load the actual value */
s->num_timers = HPET_MIN_TIMERS;
return 0;
@@ -222,6 +278,7 @@ static int hpet_pre_load(void *opaque)
static int hpet_post_load(void *opaque, int version_id)
{
HPETState *s = opaque;
+int i;
/* Recalculate the offset between the main counter and guest time */
s->hpet_offset = ticks_to_ns(s->hpet_counter) -
qemu_get_clock_ns(vm_clock);
@@ -241,6 +298,10 @@ static int hpet_post_load(void *opaque, int version_id)
hpet_pit_disable();
}
+for (i = 0; i < s->num_timers; i++) {
+kvm_hpet_msi_update(&s->timer[i]);
+}
+
return 0;
}
@@ -485,6 +546,9 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
} else if (deactivating_bit(old_val, new_val, HPET_TN_ENABLE)) {
hpet_del_timer(timer);
}
+if (modifying_bit(old_val, new_val, HPET_TN_FSB_ENABLE)) {
+kvm_hpet_msi_update(timer);
+}
break;
case HPET_TN_CFG + 4: // Interrupt capabilities
DPRINTF("qemu: invalid HPET_TN_CFG+4 write\n");
@@ -533,9 +597,11 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
break;
case HPET_TN_ROUTE:
timer->fsb = (timer->fsb & 0xULL) | new_val;
+kvm_hpet_msi_update(timer);
break;
case HPET_TN_ROUTE + 4:
timer->fsb = (new_val << 32) | (timer->fsb & 0x);
+kvm_hpet_msi_update(timer);
break;
default:
DPRINTF("qemu: invalid hpet_ram_writel\n");
@@ -667,6 +733,8 @@ static void hpet_reset(DeviceState *d)
hpet_cfg.hpet[s->hpet_id].event_timer_block_id = (uint32_t)s->capability;
hpet_cfg.hpet[s->hpet_id].address = sysbus_from_qdev(d)->mmio[0].addr;
count = 1;
+
+kvm_hpet_msi_free(s);
}
static void hpet_handle_rtc_irq(v
[PATCH v2 8/9] qemu-kvm: Refresh MSI settings after vmload
Establish a post-load notification for the MSI subsystem so that KVM can
refresh its IRQ routing after vmload.
Signed-off-by: Jan Kiszka
---
hw/msi.c | 13 +
hw/msi.h |1 +
hw/pci.c |2 ++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/hw/msi.c b/hw/msi.c
index 18f683b..0cbff17 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -453,3 +453,16 @@ unsigned int msi_nr_vectors_allocated(const PCIDevice *dev)
uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
return msi_nr_vectors(flags);
}
+
+void msi_post_load(PCIDevice *dev)
+{
+uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
+
+if (kvm_enabled() && kvm_irqchip_in_kernel()) {
+kvm_msi_free(dev);
+
+if (flags & PCI_MSI_FLAGS_ENABLE) {
+kvm_msi_update(dev);
+}
+}
+}
diff --git a/hw/msi.h b/hw/msi.h
index 5766018..6ff0607 100644
--- a/hw/msi.h
+++ b/hw/msi.h
@@ -32,6 +32,7 @@ void msi_reset(PCIDevice *dev);
void msi_notify(PCIDevice *dev, unsigned int vector);
void msi_write_config(PCIDevice *dev, uint32_t addr, uint32_t val, int len);
unsigned int msi_nr_vectors_allocated(const PCIDevice *dev);
+void msi_post_load(PCIDevice *dev);
static inline bool msi_present(const PCIDevice *dev)
{
diff --git a/hw/pci.c b/hw/pci.c
index 82e0300..07ec4f9 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -34,6 +34,7 @@
#include "device-assignment.h"
#include "qemu-objects.h"
#include "range.h"
+#include "msi.h"
//#define DEBUG_PCI
#ifdef DEBUG_PCI
@@ -342,6 +343,7 @@ static int get_pci_config_device(QEMUFile *f, void *pv,
size_t size)
memcpy(s->config, config, size);
pci_update_mappings(s);
+msi_post_load(s);
qemu_free(config);
return 0;
--
1.7.1
--
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 v2 2/9] qemu-kvm: Rename kvm_msix_message to KVMMsiMessage
This structure will be used for legacy MSI as well and will become part
of the KVM API.
Signed-off-by: Jan Kiszka
---
hw/msix.c | 10 +-
hw/pci.h | 10 ++
kvm.h |7 +++
3 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 8b68a6a..42870c5 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -51,7 +51,7 @@ int msix_supported;
static void kvm_msix_free(PCIDevice *dev)
{
int vector, changed = 0;
-struct kvm_msix_message *kmm;
+KVMMsiMessage *kmm;
for (vector = 0; vector < dev->msix_entries_nr; ++vector) {
if (dev->msix_entry_used[vector]) {
@@ -66,7 +66,7 @@ static void kvm_msix_free(PCIDevice *dev)
}
static void kvm_msix_message_from_vector(PCIDevice *dev, unsigned vector,
- struct kvm_msix_message *kmm)
+ KVMMsiMessage *kmm)
{
uint8_t *table_entry = dev->msix_table_page + vector * MSIX_ENTRY_SIZE;
@@ -78,7 +78,7 @@ static void kvm_msix_message_from_vector(PCIDevice *dev,
unsigned vector,
static void kvm_msix_update(PCIDevice *dev, int vector,
int was_masked, int is_masked)
{
-struct kvm_msix_message e = {}, *entry;
+KVMMsiMessage e = {}, *entry;
int mask_cleared = was_masked && !is_masked;
/* It is only legal to change an entry when it is masked. Therefore, it is
* enough to update the routing in kernel when mask is being cleared. */
@@ -114,7 +114,7 @@ static void kvm_msix_update(PCIDevice *dev, int vector,
static int kvm_msix_add(PCIDevice *dev, unsigned vector)
{
-struct kvm_msix_message *kmm = dev->msix_irq_entries + vector;
+KVMMsiMessage *kmm = dev->msix_irq_entries + vector;
int r;
if (!kvm_has_gsi_routing()) {
@@ -147,7 +147,7 @@ static int kvm_msix_add(PCIDevice *dev, unsigned vector)
static void kvm_msix_del(PCIDevice *dev, unsigned vector)
{
-struct kvm_msix_message *kmm;
+KVMMsiMessage *kmm;
if (dev->msix_entry_used[vector]) {
return;
diff --git a/hw/pci.h b/hw/pci.h
index dd09494..dc5df17 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -5,6 +5,7 @@
#include "qobject.h"
#include "qdev.h"
+#include "kvm.h"
/* PCI includes legacy ISA access. */
#include "isa.h"
@@ -129,13 +130,6 @@ enum {
typedef int (*msix_mask_notifier_func)(PCIDevice *, unsigned vector,
int masked);
-struct kvm_msix_message {
-uint32_t gsi;
-uint32_t addr_lo;
-uint32_t addr_hi;
-uint32_t data;
-};
-
struct PCIDevice {
DeviceState qdev;
/* PCI config space */
@@ -208,7 +202,7 @@ struct PCIDevice {
* on the rest of the region. */
target_phys_addr_t msix_page_size;
-struct kvm_msix_message *msix_irq_entries;
+KVMMsiMessage *msix_irq_entries;
msix_mask_notifier_func msix_mask_notifier;
};
diff --git a/kvm.h b/kvm.h
index b890b5d..8ece0b3 100644
--- a/kvm.h
+++ b/kvm.h
@@ -214,6 +214,13 @@ int kvm_set_irqfd(int gsi, int fd, bool assigned)
int kvm_set_ioeventfd_pio_word(int fd, uint16_t adr, uint16_t val, bool
assign);
+typedef struct KVMMsiMessage {
+uint32_t gsi;
+uint32_t addr_lo;
+uint32_t addr_hi;
+uint32_t data;
+} KVMMsiMessage;
+
int kvm_has_gsi_routing(void);
int kvm_get_irq_route_gsi(void);
int kvm_add_msix(uint32_t gsi, uint32_t addr_lo,
--
1.7.1
--
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 v2 0/9] qemu-kvm: Clean up and enhance MSI irqchip support
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but that can wait until we go upstream. This version still makes classic MSI usable in irqchip mode, now not only for PCI devices (AHCI, HDA) but also for the HPET (with msi=on). Moreover, it contains an additional patch to refresh the MSI IRQ routes after vmload. Jan Kiszka (9): qemu-kvm: Drop unneeded kvm_irq_routing_entry declaration qemu-kvm: Rename kvm_msix_message to KVMMsiMessage qemu-kvm: Refactor MSI core API of KVM qemu-kvm: Fix and clean up msix vector use/unuse hooks qemu-kvm: Move gsi bits from kvm_msix_vector_add to kvm_msi_add_message qemu-kvm: Move entry comparison into kvm_msi_update_message qemu-kvm: Add in-kernel irqchip support for MSI qemu-kvm: Refresh MSI settings after vmload qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode hw/hpet.c | 71 ++- hw/msi.c | 124 hw/msi.h |1 + hw/msix.c | 73 hw/pci.c |2 + hw/pci.h | 16 +++- kvm.h | 20 ++ qemu-kvm.c | 57 ++-- 8 files changed, 276 insertions(+), 88 deletions(-) -- 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 v2 4/9] qemu-kvm: Fix and clean up msix vector use/unuse hooks
Remove the premature return from msix_vector_use if the vector was
already in use, this could cause usage counter imbalances. In contrast,
the check for msix_entry_used on deletion was redundant. At this chance,
rename the internal API to clarify what is added/deleted here.
Signed-off-by: Jan Kiszka
---
hw/msix.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 52facd4..1bdffb6 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -108,7 +108,7 @@ static void kvm_msix_update(PCIDevice *dev, int vector,
}
}
-static int kvm_msix_add(PCIDevice *dev, unsigned vector)
+static int kvm_msix_vector_add(PCIDevice *dev, unsigned vector)
{
KVMMsiMessage *kmm = dev->msix_irq_entries + vector;
int r;
@@ -141,11 +141,8 @@ static int kvm_msix_add(PCIDevice *dev, unsigned vector)
return 0;
}
-static void kvm_msix_del(PCIDevice *dev, unsigned vector)
+static void kvm_msix_vector_del(PCIDevice *dev, unsigned vector)
{
-if (dev->msix_entry_used[vector]) {
-return;
-}
kvm_msi_message_del(&dev->msix_irq_entries[vector]);
kvm_commit_irq_routes();
}
@@ -548,11 +545,9 @@ int msix_vector_use(PCIDevice *dev, unsigned vector)
int ret;
if (vector >= dev->msix_entries_nr)
return -EINVAL;
-if (dev->msix_entry_used[vector]) {
-return 0;
-}
-if (kvm_enabled() && kvm_irqchip_in_kernel()) {
-ret = kvm_msix_add(dev, vector);
+if (kvm_enabled() && kvm_irqchip_in_kernel() &&
+!dev->msix_entry_used[vector]) {
+ret = kvm_msix_vector_add(dev, vector);
if (ret) {
return ret;
}
@@ -571,7 +566,7 @@ void msix_vector_unuse(PCIDevice *dev, unsigned vector)
return;
}
if (kvm_enabled() && kvm_irqchip_in_kernel()) {
-kvm_msix_del(dev, vector);
+kvm_msix_vector_del(dev, vector);
}
msix_clr_pending(dev, vector);
}
--
1.7.1
--
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 v2 3/9] qemu-kvm: Refactor MSI core API of KVM
Remove MSI-X from function names - the interface is valid for MSI as
well - and use KVMMsiMessage as parameter.
Signed-off-by: Jan Kiszka
---
hw/msix.c | 15 ---
kvm.h | 13 +
qemu-kvm.c | 32 +---
3 files changed, 22 insertions(+), 38 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 42870c5..52facd4 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -51,12 +51,10 @@ int msix_supported;
static void kvm_msix_free(PCIDevice *dev)
{
int vector, changed = 0;
-KVMMsiMessage *kmm;
for (vector = 0; vector < dev->msix_entries_nr; ++vector) {
if (dev->msix_entry_used[vector]) {
-kmm = &dev->msix_irq_entries[vector];
-kvm_del_msix(kmm->gsi, kmm->addr_lo, kmm->addr_hi, kmm->data);
+kvm_msi_message_del(&dev->msix_irq_entries[vector]);
changed = 1;
}
}
@@ -94,9 +92,7 @@ static void kvm_msix_update(PCIDevice *dev, int vector,
if (memcmp(entry, &e, sizeof e) != 0) {
int r;
-r = kvm_update_msix(entry->gsi, entry->addr_lo,
-entry->addr_hi, entry->data,
-e.gsi, e.addr_lo, e.addr_hi, e.data);
+r = kvm_msi_message_update(entry, &e);
if (r) {
fprintf(stderr, "%s: kvm_update_msix failed: %s\n", __func__,
strerror(-r));
@@ -131,7 +127,7 @@ static int kvm_msix_add(PCIDevice *dev, unsigned vector)
}
kmm->gsi = r;
kvm_msix_message_from_vector(dev, vector, kmm);
-r = kvm_add_msix(kmm->gsi, kmm->addr_lo, kmm->addr_hi, kmm->data);
+r = kvm_msi_message_add(kmm);
if (r < 0) {
fprintf(stderr, "%s: kvm_add_msix failed: %s\n", __func__,
strerror(-r));
return r;
@@ -147,13 +143,10 @@ static int kvm_msix_add(PCIDevice *dev, unsigned vector)
static void kvm_msix_del(PCIDevice *dev, unsigned vector)
{
-KVMMsiMessage *kmm;
-
if (dev->msix_entry_used[vector]) {
return;
}
-kmm = &dev->msix_irq_entries[vector];
-kvm_del_msix(kmm->gsi, kmm->addr_lo, kmm->addr_hi, kmm->data);
+kvm_msi_message_del(&dev->msix_irq_entries[vector]);
kvm_commit_irq_routes();
}
diff --git a/kvm.h b/kvm.h
index 8ece0b3..179eb7e 100644
--- a/kvm.h
+++ b/kvm.h
@@ -223,14 +223,11 @@ typedef struct KVMMsiMessage {
int kvm_has_gsi_routing(void);
int kvm_get_irq_route_gsi(void);
-int kvm_add_msix(uint32_t gsi, uint32_t addr_lo,
- uint32_t addr_hi, uint32_t data);
-int kvm_del_msix(uint32_t gsi, uint32_t addr_lo,
- uint32_t addr_hi, uint32_t data);
-int kvm_update_msix(uint32_t old_gsi, uint32_t old_addr_lo,
-uint32_t old_addr_hi, uint32_t old_data,
-uint32_t new_gsi, uint32_t new_addr_lo,
-uint32_t new_addr_hi, uint32_t new_data);
+
+int kvm_msi_message_add(KVMMsiMessage *msg);
+int kvm_msi_message_del(KVMMsiMessage *msg);
+int kvm_msi_message_update(KVMMsiMessage *old, KVMMsiMessage *new);
+
int kvm_commit_irq_routes(void);
int kvm_irqchip_in_kernel(void);
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 7689225..9cbc109 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -969,46 +969,40 @@ int kvm_get_irq_route_gsi(void)
return -ENOSPC;
}
-static void kvm_msix_routing_entry(struct kvm_irq_routing_entry *e,
- uint32_t gsi, uint32_t addr_lo,
- uint32_t addr_hi, uint32_t data)
+static void kvm_msi_routing_entry(struct kvm_irq_routing_entry *e,
+ KVMMsiMessage *msg)
{
-e->gsi = gsi;
+e->gsi = msg->gsi;
e->type = KVM_IRQ_ROUTING_MSI;
e->flags = 0;
-e->u.msi.address_lo = addr_lo;
-e->u.msi.address_hi = addr_hi;
-e->u.msi.data = data;
+e->u.msi.address_lo = msg->addr_lo;
+e->u.msi.address_hi = msg->addr_hi;
+e->u.msi.data = msg->data;
}
-int kvm_add_msix(uint32_t gsi, uint32_t addr_lo,
-uint32_t addr_hi, uint32_t data)
+int kvm_msi_message_add(KVMMsiMessage *msg)
{
struct kvm_irq_routing_entry e;
-kvm_msix_routing_entry(&e, gsi, addr_lo, addr_hi, data);
+kvm_msi_routing_entry(&e, msg);
return kvm_add_routing_entry(&e);
}
-int kvm_del_msix(uint32_t gsi, uint32_t addr_lo,
-uint32_t addr_hi, uint32_t data)
+int kvm_msi_message_del(KVMMsiMessage *msg)
{
struct kvm_irq_routing_entry e;
-kvm_msix_routing_entry(&e, gsi, addr_lo, addr_hi, data);
+kvm_msi_routing_entry(&e, msg);
return kvm_del_routing_entry(&e);
}
-int kvm_update_msix(uint32_t old_gsi, uint32_t old_addr_lo,
-uint32_t old_addr_hi, uint32_t old_data,
-uint32_t new_gsi, uint32_t new_addr_lo,
-uint32_t new_addr_hi, uint32_t new_data)
+int kvm_msi_message_update(KVMMsiMessage *old, KVMMsiMessage *new)
{
struct kvm_irq_routing_entry e1, e2;
-kvm_msix_routing
[PATCH v2 6/9] qemu-kvm: Move entry comparison into kvm_msi_update_message
Checking the the update chances the message content is a common task for
both MSI types.
Signed-off-by: Jan Kiszka
---
hw/msix.c | 26 +-
qemu-kvm.c | 14 +-
2 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 8c8bc18..9cee086 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -76,8 +76,10 @@ static void kvm_msix_message_from_vector(PCIDevice *dev,
unsigned vector,
static void kvm_msix_update(PCIDevice *dev, int vector,
int was_masked, int is_masked)
{
-KVMMsiMessage e = {}, *entry;
+KVMMsiMessage new_entry, *entry;
int mask_cleared = was_masked && !is_masked;
+int r;
+
/* It is only legal to change an entry when it is masked. Therefore, it is
* enough to update the routing in kernel when mask is being cleared. */
if (!mask_cleared) {
@@ -86,19 +88,17 @@ static void kvm_msix_update(PCIDevice *dev, int vector,
if (!dev->msix_entry_used[vector]) {
return;
}
-entry = dev->msix_irq_entries + vector;
-e.gsi = entry->gsi;
-kvm_msix_message_from_vector(dev, vector, &e);
-if (memcmp(entry, &e, sizeof e) != 0) {
-int r;
-r = kvm_msi_message_update(entry, &e);
-if (r) {
-fprintf(stderr, "%s: kvm_update_msix failed: %s\n", __func__,
- strerror(-r));
-exit(1);
-}
-*entry = e;
+entry = dev->msix_irq_entries + vector;
+kvm_msix_message_from_vector(dev, vector, &new_entry);
+r = kvm_msi_message_update(entry, &new_entry);
+if (r < 0) {
+fprintf(stderr, "%s: kvm_update_msix failed: %s\n", __func__,
+strerror(-r));
+exit(1);
+}
+if (r > 0) {
+*entry = new_entry;
r = kvm_commit_irq_routes();
if (r) {
fprintf(stderr, "%s: kvm_commit_irq_routes failed: %s\n", __func__,
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 7317f87..e8c2009 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -1011,10 +1011,22 @@ int kvm_msi_message_del(KVMMsiMessage *msg)
int kvm_msi_message_update(KVMMsiMessage *old, KVMMsiMessage *new)
{
struct kvm_irq_routing_entry e1, e2;
+int ret;
+
+new->gsi = old->gsi;
+if (memcmp(old, new, sizeof(KVMMsiMessage)) == 0) {
+return 0;
+}
kvm_msi_routing_entry(&e1, old);
kvm_msi_routing_entry(&e2, new);
-return kvm_update_routing_entry(&e1, &e2);
+
+ret = kvm_update_routing_entry(&e1, &e2);
+if (ret < 0) {
+return ret;
+}
+
+return 1;
}
--
1.7.1
--
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 v2 1/9] qemu-kvm: Drop unneeded kvm_irq_routing_entry declaration
Signed-off-by: Jan Kiszka --- hw/pci.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/hw/pci.h b/hw/pci.h index d584458..dd09494 100644 --- a/hw/pci.h +++ b/hw/pci.h @@ -6,8 +6,6 @@ #include "qdev.h" -struct kvm_irq_routing_entry; - /* PCI includes legacy ISA access. */ #include "isa.h" -- 1.7.1 -- 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 v2 5/9] qemu-kvm: Move gsi bits from kvm_msix_vector_add to kvm_msi_add_message
Testing support and allocating a GSI for an MSI message is required both
for MSI and MSI-X. At this chance, drop the aging version warning.
Signed-off-by: Jan Kiszka
---
hw/msix.c | 13 -
qemu-kvm.c | 11 +++
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 1bdffb6..8c8bc18 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -113,19 +113,6 @@ static int kvm_msix_vector_add(PCIDevice *dev, unsigned
vector)
KVMMsiMessage *kmm = dev->msix_irq_entries + vector;
int r;
-if (!kvm_has_gsi_routing()) {
-fprintf(stderr, "Warning: no MSI-X support found. "
-"At least kernel 2.6.30 is required for MSI-X support.\n"
- );
-return -EOPNOTSUPP;
-}
-
-r = kvm_get_irq_route_gsi();
-if (r < 0) {
-fprintf(stderr, "%s: kvm_get_irq_route_gsi failed: %s\n", __func__,
strerror(-r));
-return r;
-}
-kmm->gsi = r;
kvm_msix_message_from_vector(dev, vector, kmm);
r = kvm_msi_message_add(kmm);
if (r < 0) {
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 9cbc109..7317f87 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -984,6 +984,17 @@ static void kvm_msi_routing_entry(struct
kvm_irq_routing_entry *e,
int kvm_msi_message_add(KVMMsiMessage *msg)
{
struct kvm_irq_routing_entry e;
+int ret;
+
+if (!kvm_has_gsi_routing()) {
+return -EOPNOTSUPP;
+}
+
+ret = kvm_get_irq_route_gsi();
+if (ret < 0) {
+return ret;
+}
+msg->gsi = ret;
kvm_msi_routing_entry(&e, msg);
return kvm_add_routing_entry(&e);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for April 26th
On 04/26/2011 07:55 AM, Jan Kiszka wrote: On 2011-04-26 11:24, Juan Quintela wrote: Please, send in any agenda items you are interested in covering. From last week: Tools for resource accounting the virtual machines. Luis Antonio Galindo Castro (FunkyM0nk3y) - status of QCFG (would be nice-to-have for building machine options on top) I have a new code generator that makes QCFG much less intrusive. I've had some urgent things come up over the past couple weeks but hope to get some more time to spend on the patches very soon. I think the best merge strategy is probably going to be very incremental given my recent slowness so I'll see about trying to get a first mergable series in the next couple days. Regards, Anthony Liguori - qemu-kvm merge - status - next steps, specifically: - upstreaming in-kernel irqchip support Jan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for April 26th
On 04/26/2011 06:47 AM, Jes Sorensen wrote: On 04/26/11 11:24, Juan Quintela wrote: Please, send in any agenda items you are interested in covering. From last week: Tools for resource accounting the virtual machines. Luis Antonio Galindo Castro (FunkyM0nk3y) - Status of glib tree - next steps? I actually decided to just rewriting all of QEMU in Python and C++.. ;-) Regards, Anthony Liguori Jes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for April 26th
On 2011-04-26 11:24, Juan Quintela wrote: > > Please, send in any agenda items you are interested in covering. > > From last week: >Tools for resource accounting the virtual machines. > Luis Antonio Galindo Castro (FunkyM0nk3y) > - status of QCFG (would be nice-to-have for building machine options on top) - qemu-kvm merge - status - next steps, specifically: - upstreaming in-kernel irqchip support Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RCU+KVM: making CPU guest mode a quiescent state.
Hello Paul, I have a question about RCU + KVM. KVM does not hold any references to RCU protected data when it switches CPU into a guest mode. In fact switching to a guest mode is very similar to exiting to userspase from RCU point of view. In addition CPU may stay in a guest mode for quite a long time (up to one time slice). It looks like it will be beneficial to treat guest mode as quiescent state, just like user-mode execution. How can this be done? I was trying to find how RCU knows about cpu entering user-mode, but it seems that it does this by checking CPU mode in a timer interrupt (update_process_times()->rcu_check_callbacks()). This will not work for guest mode detection since timer interrupt will kick CPU out of a guest mode and timer interrupt will always see CPU in kernel mode. Do we have a simple function to call to notify RCU that CPU passed quiescent state which we can call just before entering guest? -- 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: [Qemu-devel] KVM call agenda for April 26th
On 04/26/11 11:24, Juan Quintela wrote: > > Please, send in any agenda items you are interested in covering. > > From last week: >Tools for resource accounting the virtual machines. > Luis Antonio Galindo Castro (FunkyM0nk3y) > - Status of glib tree - next steps? Jes -- 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
[AUTOTEST][PATCH] Add ability to call autotest client tests from kvm tests like a subtest.
Example run autotest/client/netperf2 like a server.
test.runsubtest("netperf2", tag="server", server_ip=host_ip,
client_ip=guest_ip, role='server')
Client part is called in paralel thread on virtual machine.
guest = kvm_utils.Thread(kvm_test_utils.run_autotest,
(vm, session, control_path, control_args,
timeout, outputdir, params))
guest.start()
On the guest is required to have installed the program mpstat for netpert2 test.
Netperf2 test will be changed or will be created in new version.
This patch are necessary to avoid of creation double version of test.
netperf, multicast, etc..
Signed-off-by: Jiří Župka
---
client/bin/client_logging_config.py|5 +-
client/bin/net/net_utils.py| 16 -
client/common_lib/base_job.py |2 +
client/common_lib/logging_config.py|3 +-
client/common_lib/test.py | 21 ++-
client/tests/kvm/html_report.py| 115 ++--
client/tests/kvm/kvm_test_utils.py | 19 --
client/tests/kvm/tests/subtest.py | 43
client/tests/kvm/tests_base.cfg.sample | 10 +++-
client/tests/netperf2/netperf2.py |3 +-
10 files changed, 173 insertions(+), 64 deletions(-)
create mode 100644 client/tests/kvm/tests/subtest.py
diff --git a/client/bin/client_logging_config.py
b/client/bin/client_logging_config.py
index a59b078..28c007d 100644
--- a/client/bin/client_logging_config.py
+++ b/client/bin/client_logging_config.py
@@ -12,8 +12,9 @@ class ClientLoggingConfig(logging_config.LoggingConfig):
def configure_logging(self, results_dir=None, verbose=False):
-super(ClientLoggingConfig, self).configure_logging(use_console=True,
- verbose=verbose)
+super(ClientLoggingConfig, self).configure_logging(
+ use_console=self.use_console,
+ verbose=verbose)
if results_dir:
log_dir = os.path.join(results_dir, 'debug')
diff --git a/client/bin/net/net_utils.py b/client/bin/net/net_utils.py
index 868958c..ac9b494 100644
--- a/client/bin/net/net_utils.py
+++ b/client/bin/net/net_utils.py
@@ -5,7 +5,7 @@ This library is to release in the public repository.
import commands, os, re, socket, sys, time, struct
from autotest_lib.client.common_lib import error
-import utils
+from autotest_lib.client.common_lib import utils
TIMEOUT = 10 # Used for socket timeout and barrier timeout
@@ -27,6 +27,20 @@ class network_utils(object):
utils.system('/sbin/ifconfig -a')
+def get_corespond_local_ip(self, query_ip, netmask="24"):
+"""
+Get ip address in local system which can communicate with quert_ip.
+
+@param query_ip: IP of client which want communicate with autotest
machine.
+@return: IP address which can communicate with query_ip
+"""
+ip = utils.system_output("ip addr show to %s/%s" % (query_ip, netmask))
+ip = re.search(r"inet ([0-9.]*)/",ip)
+if ip is None:
+return ip
+return ip.group(1)
+
+
def disable_ip_local_loopback(self, ignore_status=False):
utils.system("echo '1' > /proc/sys/net/ipv4/route/no_local_loopback",
ignore_status=ignore_status)
diff --git a/client/common_lib/base_job.py b/client/common_lib/base_job.py
index 843c0e8..eef9efc 100644
--- a/client/common_lib/base_job.py
+++ b/client/common_lib/base_job.py
@@ -1117,6 +1117,7 @@ class base_job(object):
tag_parts = []
# build up the parts of the tag used for the test name
+master_testpath = dargs.get('master_testpath', "")
base_tag = dargs.pop('tag', None)
if base_tag:
tag_parts.append(str(base_tag))
@@ -1132,6 +1133,7 @@ class base_job(object):
if subdir_tag:
tag_parts.append(subdir_tag)
subdir = '.'.join([testname] + tag_parts)
+subdir = os.path.join(master_testpath, subdir)
tag = '.'.join(tag_parts)
return full_testname, subdir, tag
diff --git a/client/common_lib/logging_config.py
b/client/common_lib/logging_config.py
index afe754a..9114d7a 100644
--- a/client/common_lib/logging_config.py
+++ b/client/common_lib/logging_config.py
@@ -32,9 +32,10 @@ class LoggingConfig(object):
fmt='%(asctime)s %(levelname)-5.5s| %(message)s',
datefmt='%H:%M:%S')
-def __init__(self):
+def __init__(self, use_console=True):
self.logger = logging.getLogger()
self.global_level = logging.DEBUG
+self.use_console = use_console
@classmethod
diff --git a/client/common_lib/test.py b/client/common_lib/test.py
index c55d23b..b1a0904 100644
--- a/client/common_lib/test.py
+++ b/client/common_lib/test.py
@@ -465,6 +465,24 @@ class base_test(object):
Re: [PATCH 1/5] KVM: mmio_fault_cr2 is not used.
On 04/26/2011 11:25 AM, Gleb Natapov wrote: Ping? What about those patches? 2/5 should be dropped, but others are not yet applied too as far as I see. Applied now, thanks for the reminder. -- 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: kvm crashes with spice while loading qxl
On 04/26/11 11:06, Jan Kiszka wrote: On 2011-04-26 10:53, Gerd Hoffmann wrote: Two general issues with dropping the global mutex like this: - The caller of mutex_unlock is responsible for maintaining cpu_single_env across the unlocked phase (that's related to the abort above). This is true for qemu-kvm only, right? Nope, this applies to both implementations. Oops. qemu-kvm specific patches which add the cpu_single_env tracking (not polished yet) are here: http://cgit.freedesktop.org/spice/qemu/log/?h=spice.kvm.v28 Cannot spot that quickly: In which way are they specific to qemu-kvm? cpu_single_env bookeeping. But if upstream needs that too having specific patches is pretty pointless. I'll go fix it up upstream then. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] virtio_balloon: disable oom killer when fill balloon
On Tue, Apr 26, 2011 at 5:28 PM, Minchan Kim wrote:
> Please resend this with [2/2] to linux-mm.
>
> On Tue, Apr 26, 2011 at 5:59 PM, Dave Young wrote:
>> When memory pressure is high, virtio ballooning will probably cause oom
>> killing.
>> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it
>> will make memory becoming low then memory alloc of other processes will
>> trigger
>> oom killing. It is not desired behaviour.
>
> I can't understand why it is undesirable.
> Why do we have to handle it specially?
>
Suppose user run some random memory hogging process while ballooning
it will be undesirable.
>
>>
>> Here disable oom killer in fill_balloon to address this issue.
>> Add code comment as KOSAKI Motohiro's suggestion.
>>
>> Signed-off-by: Dave Young
>> ---
>> drivers/virtio/virtio_balloon.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2011-04-26
>> 11:39:14.053118406 +0800
>> +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26
>> 16:54:56.419741542 +0800
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> struct virtio_balloon
>> {
>> @@ -102,6 +103,12 @@ static void fill_balloon(struct virtio_b
>> /* We can only do one array worth at a time. */
>> num = min(num, ARRAY_SIZE(vb->pfns));
>>
>> + /* Disable oom killer for indirect oom due to our memory consuming
>> + * Currently only hibernation code use oom_killer_disable,
>
> Hmm, Please look at current mmotm. Now oom_killer_disabled is used by
> do_try_to_free_pages in mmotm so it could make unnecessary oom kill.
>
> BTW, I can't understand why we need to handle virtio by special.
> Could you explain it in detail? :)
>
>
>
> --
> Kind regards,
> Minchan Kim
>
--
Regards
dave
--
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: Does macvtap support host to guest communication?
On Tue, Apr 19, 2011 at 02:14:25PM +0200, Arnd Bergmann wrote: > On Monday 18 April 2011, Asias He wrote: > > > > > > If you want a regular device to be able to send to a macvlan > > > port, that would require at least these changes: > > > > > > * Add an option to put a plain device into macvlan-bridge mode > > > * Add support for that option into iproute2 > > > * Add a hook into dev_queue_xmit() to check for macvlan ports > > > > Cool! Arnd, mind to add this feature to macvtap? > > No, not after I just explained why I haven't done it before > and why it's so controversial. > > Also, I have moved on to other projects and am no longer doing > active development of the macvtap driver. I'd be happy to > pass on the ownership to someone else and help him or her extend > it. > > Arnd There's overlap between macvtap and some ongoing work on vhost-net. In particular there are efforts to add zero copy and multiqueue support. So if you like, apply something like the below: Signed-off-by: Michael S. Tsirkin diff --git a/MAINTAINERS b/MAINTAINERS index 649600c..28861a4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4034,6 +4034,13 @@ S: Maintained F: drivers/net/macvlan.c F: include/linux/if_macvlan.h +MACVTAP DRIVER +M: Michael S. Tsirkin +M: Arnd Bergmann +L: net...@vger.kernel.org +S: Maintained +F: drivers/net/macvtap.c + MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7 M: Michael Kerrisk W: http://www.kernel.org/doc/man-pages -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm crashes with spice while loading qxl
On Tue, Apr 26, 2011 at 10:53:04AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> [ ... back online now ... ]
>
> >>/var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.14.0/qemu-kvm.c:1724:
> >>kvm_mutex_unlock: Assertion `!cpu_single_env' failed.
>
> >That's a spice bug. In fact, there are a lot of
> >qemu_mutex_lock/unlock_iothread in that subsystem. I bet at least a few
> >of them can cause even more subtle problems.
> >
> >Two general issues with dropping the global mutex like this:
> > - The caller of mutex_unlock is responsible for maintaining
> >cpu_single_env across the unlocked phase (that's related to the
> >abort above).
>
> This is true for qemu-kvm only, right?
>
> qemu-kvm specific patches which add the cpu_single_env tracking (not
> polished yet) are here:
>
> http://cgit.freedesktop.org/spice/qemu/log/?h=spice.kvm.v28
>
> > - Dropping the lock in the middle of a callback is risky. That may
> >enable re-entrances of code sections that weren't designed for this
>
> Hmm, indeed.
>
> >Spice requires a careful review regarding such issues. Or it should
> >pioneer with introducing its own lock so that we can handle at least
> >related I/O activities over the VCPUs without holding the global mutex
> >(but I bet it's not the simplest candidate for such a new scheme).
>
> spice/qxl used to have its own locking scheme. That didn't work out
> though. spice server is threaded and calls back into qxl from spice
> thread context, and some of these callbacks need access to qemu data
> structures (display surface) and thus lock protection which covers
> more than just the spice subsystem.
>
> I'll look hard again whenever I can find a way out of this
> (preferably drop the need for the global lock somehow). For now I'm
> pretty busy with the email backlog though ...
>
We (Hans, Uri, and Me) have already sent a fix for this, it seems to have
passed everyone's testing, and it basically does just that - drops the
use of the mutex. It's in
http://cgit.freedesktop.org/spice/qemu/log/?h=spice.v32.kvm,
see the patches:
qxl/spice-display: move pipe to ssd
qxl: implement get_command in vga mode without locks
qxl/spice: remove qemu_mutex_{un,}lock_iothread around dispatcher
hw/qxl-render: drop cursor locks, replace with pipe
And specifically the comments too.
Alon
> cheers,
> Gerd
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] virtio_balloon: disable oom killer when fill balloon
Please resend this with [2/2] to linux-mm.
On Tue, Apr 26, 2011 at 5:59 PM, Dave Young wrote:
> When memory pressure is high, virtio ballooning will probably cause oom
> killing.
> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it
> will make memory becoming low then memory alloc of other processes will
> trigger
> oom killing. It is not desired behaviour.
I can't understand why it is undesirable.
Why do we have to handle it specially?
>
> Here disable oom killer in fill_balloon to address this issue.
> Add code comment as KOSAKI Motohiro's suggestion.
>
> Signed-off-by: Dave Young
> ---
> drivers/virtio/virtio_balloon.c | 8
> 1 file changed, 8 insertions(+)
>
> --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2011-04-26
> 11:39:14.053118406 +0800
> +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26 16:54:56.419741542
> +0800
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> struct virtio_balloon
> {
> @@ -102,6 +103,12 @@ static void fill_balloon(struct virtio_b
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
>
> + /* Disable oom killer for indirect oom due to our memory consuming
> + * Currently only hibernation code use oom_killer_disable,
Hmm, Please look at current mmotm. Now oom_killer_disabled is used by
do_try_to_free_pages in mmotm so it could make unnecessary oom kill.
BTW, I can't understand why we need to handle virtio by special.
Could you explain it in detail? :)
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM call agenda for April 26th
Please, send in any agenda items you are interested in covering. >From last week: Tools for resource accounting the virtual machines. Luis Antonio Galindo Castro (FunkyM0nk3y) Later, Juan. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM storage
Can anyone suggest me some interesting ideas related to KVM storage (IOV,iSCSI,filesystem etc )to implement .. regards, Ajay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm crashes with spice while loading qxl
On 2011-04-26 10:53, Gerd Hoffmann wrote: > Hi, > > [ ... back online now ... ] > >>> /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.14.0/qemu-kvm.c:1724: >>> >>> kvm_mutex_unlock: Assertion `!cpu_single_env' failed. > >> That's a spice bug. In fact, there are a lot of >> qemu_mutex_lock/unlock_iothread in that subsystem. I bet at least a few >> of them can cause even more subtle problems. >> >> Two general issues with dropping the global mutex like this: >> - The caller of mutex_unlock is responsible for maintaining >> cpu_single_env across the unlocked phase (that's related to the >> abort above). > > This is true for qemu-kvm only, right? Nope, this applies to both implementations. > > qemu-kvm specific patches which add the cpu_single_env tracking (not > polished yet) are here: > > http://cgit.freedesktop.org/spice/qemu/log/?h=spice.kvm.v28 Cannot spot that quickly: In which way are they specific to qemu-kvm? If they are, try to focus on upstream first. The qemu-kvm differences are virtually deprecated, and I hope we can remove them really soon now (my patches are all ready). > >> - Dropping the lock in the middle of a callback is risky. That may >> enable re-entrances of code sections that weren't designed for this > > Hmm, indeed. > >> Spice requires a careful review regarding such issues. Or it should >> pioneer with introducing its own lock so that we can handle at least >> related I/O activities over the VCPUs without holding the global mutex >> (but I bet it's not the simplest candidate for such a new scheme). > > spice/qxl used to have its own locking scheme. That didn't work out > though. spice server is threaded and calls back into qxl from spice > thread context, and some of these callbacks need access to qemu data > structures (display surface) and thus lock protection which covers more > than just the spice subsystem. > > I'll look hard again whenever I can find a way out of this (preferably > drop the need for the global lock somehow). For now I'm pretty busy > with the email backlog though ... Yeah, I can imagine... Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm crashes with spice while loading qxl
Hi, [ ... back online now ... ] /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.14.0/qemu-kvm.c:1724: kvm_mutex_unlock: Assertion `!cpu_single_env' failed. That's a spice bug. In fact, there are a lot of qemu_mutex_lock/unlock_iothread in that subsystem. I bet at least a few of them can cause even more subtle problems. Two general issues with dropping the global mutex like this: - The caller of mutex_unlock is responsible for maintaining cpu_single_env across the unlocked phase (that's related to the abort above). This is true for qemu-kvm only, right? qemu-kvm specific patches which add the cpu_single_env tracking (not polished yet) are here: http://cgit.freedesktop.org/spice/qemu/log/?h=spice.kvm.v28 - Dropping the lock in the middle of a callback is risky. That may enable re-entrances of code sections that weren't designed for this Hmm, indeed. Spice requires a careful review regarding such issues. Or it should pioneer with introducing its own lock so that we can handle at least related I/O activities over the VCPUs without holding the global mutex (but I bet it's not the simplest candidate for such a new scheme). spice/qxl used to have its own locking scheme. That didn't work out though. spice server is threaded and calls back into qxl from spice thread context, and some of these callbacks need access to qemu data structures (display surface) and thus lock protection which covers more than just the spice subsystem. I'll look hard again whenever I can find a way out of this (preferably drop the need for the global lock somehow). For now I'm pretty busy with the email backlog though ... cheers, Gerd -- 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: LEAVE emulation infinite loop
On 04/25/2011 12:05 PM, Matteo Signorini wrote: Hi to All, I fixed the previously highlighted error, calling the right pop emulation function but still get the same error, an infinite "leave" emulation loop. IMHO this is not an emulation error since x86_decode_insn and x86_emulate_insn return a correct value ( r=0 ) so I don't understand what I'm doing wrong... could you please give me an hint to fix it? No idea, sorry, you'll have to debug 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
[PATCH v2] virtio_balloon: disable oom killer when fill balloon
When memory pressure is high, virtio ballooning will probably cause oom killing.
Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it
will make memory becoming low then memory alloc of other processes will trigger
oom killing. It is not desired behaviour.
Here disable oom killer in fill_balloon to address this issue.
Add code comment as KOSAKI Motohiro's suggestion.
Signed-off-by: Dave Young
---
drivers/virtio/virtio_balloon.c |8
1 file changed, 8 insertions(+)
--- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2011-04-26
11:39:14.053118406 +0800
+++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26 16:54:56.419741542
+0800
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
struct virtio_balloon
{
@@ -102,6 +103,12 @@ static void fill_balloon(struct virtio_b
/* We can only do one array worth at a time. */
num = min(num, ARRAY_SIZE(vb->pfns));
+ /* Disable oom killer for indirect oom due to our memory consuming
+* Currently only hibernation code use oom_killer_disable,
+* hibernation will freeze us before disable oom killer, so
+* It's safe here without locks.
+*/
+ oom_killer_disable();
for (vb->num_pfns = 0; vb->num_pfns < num; vb->num_pfns++) {
struct page *page = alloc_page(GFP_HIGHUSER | __GFP_NORETRY |
__GFP_NOMEMALLOC | __GFP_NOWARN);
@@ -119,6 +126,7 @@ static void fill_balloon(struct virtio_b
vb->num_pages++;
list_add(&page->lru, &vb->pages);
}
+ oom_killer_enable();
/* Didn't get any? Oh well. */
if (vb->num_pfns == 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: [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon
On Tue, Apr 26, 2011 at 3:22 PM, KOSAKI Motohiro
wrote:
>> On Tue, Apr 26, 2011 at 2:38 PM, KOSAKI Motohiro
>> wrote:
>> >> When memory pressure is high, virtio ballooning will probably cause oom
>> >> killing.
>> >> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom
>> >> it
>> >> will make memory becoming low then memory alloc of other processes will
>> >> trigger
>> >> oom killing. It is not desired behaviour.
>> >>
>> >> Here disable oom killer in fill_balloon to address this issue.
>> >>
>> >> Signed-off-by: Dave Young
>> >> ---
>> >> drivers/virtio/virtio_balloon.c | 3 +++
>> >> 1 file changed, 3 insertions(+)
>> >>
>> >> --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2010-10-13
>> >> 10:14:38.0 +0800
>> >> +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26
>> >> 11:38:43.979785141 +0800
>> >> @@ -25,6 +25,7 @@
>> >> #include
>> >> #include
>> >> #include
>> >> +#include
>> >>
>> >> struct virtio_balloon
>> >> {
>> >> @@ -102,6 +103,7 @@ static void fill_balloon(struct virtio_b
>> >> /* We can only do one array worth at a time. */
>> >> num = min(num, ARRAY_SIZE(vb->pfns));
>> >>
>> >> + oom_killer_disable();
>> >
>> > I think this patch need proper comment at least. My first impression
>> > is, "Hm, __GFP_NORETRY should prevent oom, why is this necessary?".
>> > So, this actually prevent _another_ thread call out_of_memory().
>>
>> Thanks, will fix.
>>
>> > Also, Here doesn't have any exclusion against hibernation (ie another
>> > oom_killer_disable() callsite). It should be described why lock is
>> > unnecessary.
>>
>> Good catch, but lock should better be handled in oom_killer_disable
>> function itself,
>> What do you think?
>>
>> For oom killer multi user there's more problem, if process A disable
>> oom killer then Process B enable oom killer, it is not A want to see,
>> Any thoughts?
>
> If baloon and hibernation don't have any implicit exclusion, you are
> right.
For this case, hibernation will freeze balloon thread before call
oom_killer_disable, so there's no problem.
If we consider future users of oom_killer_disabled, we will
have to deal with it.
>
> Sorry, I don't virtio internal. please don't ask me.
>
>
>
>
--
Regards
dave
--
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] KVM: SVM: Make dump_vmcb static, reduce text
On Mon, Apr 25, 2011 at 01:00:50AM -0400, Joe Perches wrote:
> dump_vmcb isn't used outside this module, make it static.
> Shrink text and object by ~1% by standardizing formats.
>
> $ size arch/x86/kvm/svm.o*
>text data bss dec hex filename
> 52910 580 10072 63562f84a arch/x86/kvm/svm.o.new
> 53563 580 10072 64215fad7 arch/x86/kvm/svm.o.old
>
> Signed-off-by: Joe Perches
Looks good.
Acked-by: Joerg Roedel
> ---
> arch/x86/kvm/svm.c | 176
>
> 1 files changed, 94 insertions(+), 82 deletions(-)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index a6bf2ad..1b9f67e 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -3188,97 +3188,109 @@ static int (*svm_exit_handlers[])(struct vcpu_svm
> *svm) = {
> [SVM_EXIT_NPF] = pf_interception,
> };
>
> -void dump_vmcb(struct kvm_vcpu *vcpu)
> +static void dump_vmcb(struct kvm_vcpu *vcpu)
> {
> struct vcpu_svm *svm = to_svm(vcpu);
> struct vmcb_control_area *control = &svm->vmcb->control;
> struct vmcb_save_area *save = &svm->vmcb->save;
>
> pr_err("VMCB Control Area:\n");
> - pr_err("cr_read:%04x\n", control->intercept_cr & 0x);
> - pr_err("cr_write: %04x\n", control->intercept_cr >> 16);
> - pr_err("dr_read:%04x\n", control->intercept_dr & 0x);
> - pr_err("dr_write: %04x\n", control->intercept_dr >> 16);
> - pr_err("exceptions: %08x\n", control->intercept_exceptions);
> - pr_err("intercepts: %016llx\n", control->intercept);
> - pr_err("pause filter count: %d\n", control->pause_filter_count);
> - pr_err("iopm_base_pa: %016llx\n", control->iopm_base_pa);
> - pr_err("msrpm_base_pa: %016llx\n", control->msrpm_base_pa);
> - pr_err("tsc_offset: %016llx\n", control->tsc_offset);
> - pr_err("asid: %d\n", control->asid);
> - pr_err("tlb_ctl:%d\n", control->tlb_ctl);
> - pr_err("int_ctl:%08x\n", control->int_ctl);
> - pr_err("int_vector: %08x\n", control->int_vector);
> - pr_err("int_state: %08x\n", control->int_state);
> - pr_err("exit_code: %08x\n", control->exit_code);
> - pr_err("exit_info1: %016llx\n", control->exit_info_1);
> - pr_err("exit_info2: %016llx\n", control->exit_info_2);
> - pr_err("exit_int_info: %08x\n", control->exit_int_info);
> - pr_err("exit_int_info_err: %08x\n", control->exit_int_info_err);
> - pr_err("nested_ctl: %lld\n", control->nested_ctl);
> - pr_err("nested_cr3: %016llx\n", control->nested_cr3);
> - pr_err("event_inj: %08x\n", control->event_inj);
> - pr_err("event_inj_err: %08x\n", control->event_inj_err);
> - pr_err("lbr_ctl:%lld\n", control->lbr_ctl);
> - pr_err("next_rip: %016llx\n", control->next_rip);
> + pr_err("%-20s%04x\n", "cr_read:", control->intercept_cr & 0x);
> + pr_err("%-20s%04x\n", "cr_write:", control->intercept_cr >> 16);
> + pr_err("%-20s%04x\n", "dr_read:", control->intercept_dr & 0x);
> + pr_err("%-20s%04x\n", "dr_write:", control->intercept_dr >> 16);
> + pr_err("%-20s%08x\n", "exceptions:", control->intercept_exceptions);
> + pr_err("%-20s%016llx\n", "intercepts:", control->intercept);
> + pr_err("%-20s%d\n", "pause filter count:", control->pause_filter_count);
> + pr_err("%-20s%016llx\n", "iopm_base_pa:", control->iopm_base_pa);
> + pr_err("%-20s%016llx\n", "msrpm_base_pa:", control->msrpm_base_pa);
> + pr_err("%-20s%016llx\n", "tsc_offset:", control->tsc_offset);
> + pr_err("%-20s%d\n", "asid:", control->asid);
> + pr_err("%-20s%d\n", "tlb_ctl:", control->tlb_ctl);
> + pr_err("%-20s%08x\n", "int_ctl:", control->int_ctl);
> + pr_err("%-20s%08x\n", "int_vector:", control->int_vector);
> + pr_err("%-20s%08x\n", "int_state:", control->int_state);
> + pr_err("%-20s%08x\n", "exit_code:", control->exit_code);
> + pr_err("%-20s%016llx\n", "exit_info1:", control->exit_info_1);
> + pr_err("%-20s%016llx\n", "exit_info2:", control->exit_info_2);
> + pr_err("%-20s%08x\n", "exit_int_info:", control->exit_int_info);
> + pr_err("%-20s%08x\n", "exit_int_info_err:", control->exit_int_info_err);
> + pr_err("%-20s%lld\n", "nested_ctl:", control->nested_ctl);
> + pr_err("%-20s%016llx\n", "nested_cr3:", control->nested_cr3);
> + pr_err("%-20s%08x\n", "event_inj:", control->event_inj);
> + pr_err("%-20s%08x\n", "event_inj_err:", control->event_inj_err);
> + pr_err("%-20s%lld\n", "lbr_ctl:", control->lbr_ctl);
> + pr_err("%-20s%016llx\n", "next_rip:", control->next_rip);
> pr_err("VMCB State Save Area:\n");
> - pr_err("es: s: %04x a: %04x l: %08x b: %016llx\n",
> - save->es.se
Re: [PATCH 1/5] KVM: mmio_fault_cr2 is not used.
Ping? What about those patches? 2/5 should be dropped, but others are
not yet applied too as far as I see.
On Tue, Apr 12, 2011 at 12:36:21PM +0300, Gleb Natapov wrote:
> Remove unused variable mmio_fault_cr2.
>
> Signed-off-by: Gleb Natapov
> ---
> arch/x86/include/asm/kvm_host.h |1 -
> arch/x86/kvm/x86.c |2 +-
> 2 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index bd57639..c1a7f54 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -358,7 +358,6 @@ struct kvm_vcpu_arch {
> struct fpu guest_fpu;
> u64 xcr0;
>
> - gva_t mmio_fault_cr2;
> struct kvm_pio_request pio;
> void *pio_data;
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 1d5a7f4..b568779 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4504,7 +4504,7 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu,
> struct decode_cache *c = &vcpu->arch.emulate_ctxt.decode;
>
> kvm_clear_exception_queue(vcpu);
> - vcpu->arch.mmio_fault_cr2 = cr2;
> +
> /*
>* TODO: fix emulate.c to use guest_read/write_register
>* instead of direct ->regs accesses, can save hundred cycles
> --
> 1.7.2.3
>
> --
> 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
--
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 1/1 v2] KVM: MMU: Optimize guest page table walk
On 04/26/2011 10:45 AM, Jan Kiszka wrote:
On 2011-04-26 09:42, Avi Kivity wrote:
> On 04/25/2011 11:04 AM, Jan Kiszka wrote:
>> > +
>> > +ptep_user = (pt_element_t __user *)((void *)host_addr +
>> offset);
>> > +if (get_user(pte, ptep_user)) {
>>
>> This doesn't work for x86-32: pte is 64 bit, but get_user is only
>> defined up to 32 bit on that platform.
>>
>
> I actually considered this, and saw:
>
> #ifdef CONFIG_X86_32
> #define __get_user_8(__ret_gu, __val_gu, ptr)\
> __get_user_x(X, __ret_gu, __val_gu, ptr)
> #else
> #define __get_user_8(__ret_gu, __val_gu, ptr)\
> __get_user_x(8, __ret_gu, __val_gu, ptr)
> #endif
>
> #define get_user(x, ptr)\
> ({\
> int __ret_gu;\
> unsigned long __val_gu;\
> __chk_user_ptr(ptr);\
> might_fault();\
> switch (sizeof(*(ptr))) {\
>
> ...
>
> case 8:\
> __get_user_8(__ret_gu, __val_gu, ptr);\
> break;\
>
> ...
>
> }\
> (x) = (__typeof__(*(ptr)))__val_gu;\
> __ret_gu;\
> })
>
> so it should work. How does it fail?
On x86-32, the above macro resolves to __get_user_X, an undefined symbol.
Tricky stuff.
--
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: performance of virtual functions compared to virtio
On 04/25/2011 08:46 PM, David Ahern wrote: > > Note I think in both cases we can make significant improvements: > - for VFs, steer device interrupts to the cpus which run the vcpus that > will receive the interrupts eventually (ISTR some work about this, but > not sure) I don't understand your point here. I thought interrupts for the VF were only delivered to the guest, not the host. Interrupts are delivered to the host, which the forwards them to the guest. Virtualization hardware on x86 does not allow direct-to-guest interrupt delivery. -- 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: performance of virtual functions compared to virtio
On 04/25/2011 08:49 PM, David Ahern wrote: > > There are several copies. > > qemu's virtio-net implementation incurs a copy on tx and on rx when > calling the kernel; in addition there is also an internal copy: > > /* copy in packet. ugh */ > len = iov_from_buf(sg, elem.in_num, > buf + offset, size - offset); > > In principle vhost-net can avoid the tx copy, but I think now we have 1 > copy on rx and tx each. So there is a copy internal to qemu, then from qemu to the host tap device and then tap device to a physical NIC if the packet is leaving the host? There is no internal copy on tx, just rx. So: virtio-net: 1 internal rx, 1 kernel/user rx, 1 kernel/user tx vhost-net: 1 internal rx, 1 internal tx Is that what the zero-copy patch set is attempting - bypassing the transmit copy to the macvtap device? Yes. > > If a host interface is dedicated to backing a vhost-net interface (say > if you have an SR/IOV card) then you can in principle avoid the rx copy > as well. > > An alternative to avoiding the copies is to use a dma engine, like I > mentioned. > How does the DMA engine differ from the zero-copy patch set? The DMA engine does not avoid the copy, it merely uses a device other than the cpu to perform it. It offloads the cpu but still loads the interconnect. True zero-copy avoids both the cpu load and the interconnect load. -- 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 1/1 v2] KVM: MMU: Optimize guest page table walk
On 2011-04-26 09:42, Avi Kivity wrote:
> On 04/25/2011 11:04 AM, Jan Kiszka wrote:
>> > +
>> > +ptep_user = (pt_element_t __user *)((void *)host_addr +
>> offset);
>> > +if (get_user(pte, ptep_user)) {
>>
>> This doesn't work for x86-32: pte is 64 bit, but get_user is only
>> defined up to 32 bit on that platform.
>>
>
> I actually considered this, and saw:
>
> #ifdef CONFIG_X86_32
> #define __get_user_8(__ret_gu, __val_gu, ptr)\
> __get_user_x(X, __ret_gu, __val_gu, ptr)
> #else
> #define __get_user_8(__ret_gu, __val_gu, ptr)\
> __get_user_x(8, __ret_gu, __val_gu, ptr)
> #endif
>
> #define get_user(x, ptr)\
> ({\
> int __ret_gu;\
> unsigned long __val_gu;\
> __chk_user_ptr(ptr);\
> might_fault();\
> switch (sizeof(*(ptr))) {\
>
> ...
>
> case 8:\
> __get_user_8(__ret_gu, __val_gu, ptr);\
> break;\
>
> ...
>
> }\
> (x) = (__typeof__(*(ptr)))__val_gu;\
> __ret_gu;\
> })
>
> so it should work. How does it fail?
On x86-32, the above macro resolves to __get_user_X, an undefined symbol.
>
>> Avi, what's your 32-bit buildbot doing? :)
>
> I regularly autotest on x86_64, not on i386, sorry.
Good that it's included in my kvm-kmod buildbot.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/1 v2] KVM: MMU: Optimize guest page table walk
On 04/25/2011 11:04 AM, Jan Kiszka wrote:
> +
> + ptep_user = (pt_element_t __user *)((void *)host_addr + offset);
> + if (get_user(pte, ptep_user)) {
This doesn't work for x86-32: pte is 64 bit, but get_user is only
defined up to 32 bit on that platform.
I actually considered this, and saw:
#ifdef CONFIG_X86_32
#define __get_user_8(__ret_gu, __val_gu, ptr)\
__get_user_x(X, __ret_gu, __val_gu, ptr)
#else
#define __get_user_8(__ret_gu, __val_gu, ptr)\
__get_user_x(8, __ret_gu, __val_gu, ptr)
#endif
#define get_user(x, ptr)\
({\
int __ret_gu;\
unsigned long __val_gu;\
__chk_user_ptr(ptr);\
might_fault();\
switch (sizeof(*(ptr))) {\
...
case 8:\
__get_user_8(__ret_gu, __val_gu, ptr);\
break;\
...
}\
(x) = (__typeof__(*(ptr)))__val_gu;\
__ret_gu;\
})
so it should work. How does it fail?
Avi, what's your 32-bit buildbot doing? :)
I regularly autotest on x86_64, not on i386, sorry.
--
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 1/2] virtio_balloon: disable oom killer when fill balloon
> On Tue, Apr 26, 2011 at 2:38 PM, KOSAKI Motohiro
> wrote:
> >> When memory pressure is high, virtio ballooning will probably cause oom
> >> killing.
> >> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it
> >> will make memory becoming low then memory alloc of other processes will
> >> trigger
> >> oom killing. It is not desired behaviour.
> >>
> >> Here disable oom killer in fill_balloon to address this issue.
> >>
> >> Signed-off-by: Dave Young
> >> ---
> >> drivers/virtio/virtio_balloon.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2010-10-13
> >> 10:14:38.0 +0800
> >> +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26
> >> 11:38:43.979785141 +0800
> >> @@ -25,6 +25,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> struct virtio_balloon
> >> {
> >> @@ -102,6 +103,7 @@ static void fill_balloon(struct virtio_b
> >> /* We can only do one array worth at a time. */
> >> num = min(num, ARRAY_SIZE(vb->pfns));
> >>
> >> + oom_killer_disable();
> >
> > I think this patch need proper comment at least. My first impression
> > is, "Hm, __GFP_NORETRY should prevent oom, why is this necessary?".
> > So, this actually prevent _another_ thread call out_of_memory().
>
> Thanks, will fix.
>
> > Also, Here doesn't have any exclusion against hibernation (ie another
> > oom_killer_disable() callsite). It should be described why lock is
> > unnecessary.
>
> Good catch, but lock should better be handled in oom_killer_disable
> function itself,
> What do you think?
>
> For oom killer multi user there's more problem, if process A disable
> oom killer then Process B enable oom killer, it is not A want to see,
> Any thoughts?
If baloon and hibernation don't have any implicit exclusion, you are
right.
Sorry, I don't virtio internal. please don't ask me.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon
On Tue, Apr 26, 2011 at 2:38 PM, KOSAKI Motohiro
wrote:
>> When memory pressure is high, virtio ballooning will probably cause oom
>> killing.
>> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it
>> will make memory becoming low then memory alloc of other processes will
>> trigger
>> oom killing. It is not desired behaviour.
>>
>> Here disable oom killer in fill_balloon to address this issue.
>>
>> Signed-off-by: Dave Young
>> ---
>> drivers/virtio/virtio_balloon.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2010-10-13
>> 10:14:38.0 +0800
>> +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26 11:38:43.979785141
>> +0800
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> struct virtio_balloon
>> {
>> @@ -102,6 +103,7 @@ static void fill_balloon(struct virtio_b
>> /* We can only do one array worth at a time. */
>> num = min(num, ARRAY_SIZE(vb->pfns));
>>
>> + oom_killer_disable();
>
> I think this patch need proper comment at least. My first impression
> is, "Hm, __GFP_NORETRY should prevent oom, why is this necessary?".
> So, this actually prevent _another_ thread call out_of_memory().
Thanks, will fix.
> Also, Here doesn't have any exclusion against hibernation (ie another
> oom_killer_disable() callsite). It should be described why lock is
> unnecessary.
Good catch, but lock should better be handled in oom_killer_disable
function itself,
What do you think?
For oom killer multi user there's more problem, if process A disable
oom killer then Process B enable oom killer, it is not A want to see,
Any thoughts?
>
> Thanks.
>
>
>> for (vb->num_pfns = 0; vb->num_pfns < num; vb->num_pfns++) {
>> struct page *page = alloc_page(GFP_HIGHUSER | __GFP_NORETRY |
>> __GFP_NOMEMALLOC | __GFP_NOWARN);
>> @@ -119,6 +121,7 @@ static void fill_balloon(struct virtio_b
>> vb->num_pages++;
>> list_add(&page->lru, &vb->pages);
>> }
>> + oom_killer_enable();
>>
>> /* Didn't get any? Oh well. */
>> if (vb->num_pfns == 0)
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
--
Regards
dave
--
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
