[PATCH 0/2] Updating CTCS test suite
Use new git repo, rename module, update KVM test definitions. Please bear with me when you see the binary patches, didn't have the patience to remove them :) Lucas Meneghel Rodrigues (2): client.tests: Move cerberus to ctcs, use new source repo KVM test: Update ctcs run on guests client/tests/cerberus/0001-Fix-CTCS2-Build.patch | 212 .../0002-Fix-CTCS2-build-in-64-bit-boxes.patch | 192 -- client/tests/cerberus/cerberus.py | 109 -- client/tests/cerberus/control | 20 -- client/tests/cerberus/ctcs2.tar.bz2| Bin 2131977 - 0 bytes client/tests/ctcs/control | 19 ++ client/tests/ctcs/ctcs.py | 100 + client/tests/ctcs/ctcs.tar.bz2 | Bin 0 - 1337538 bytes client/tests/kvm/autotest_control/cerberus.control | 20 -- client/tests/kvm/autotest_control/ctcs.control | 19 ++ client/tests/kvm/tests_base.cfg.sample |4 +- 11 files changed, 140 insertions(+), 555 deletions(-) delete mode 100644 client/tests/cerberus/0001-Fix-CTCS2-Build.patch delete mode 100644 client/tests/cerberus/0002-Fix-CTCS2-build-in-64-bit-boxes.patch delete mode 100644 client/tests/cerberus/cerberus.py delete mode 100644 client/tests/cerberus/control delete mode 100644 client/tests/cerberus/ctcs2.tar.bz2 create mode 100644 client/tests/ctcs/control create mode 100644 client/tests/ctcs/ctcs.py create mode 100644 client/tests/ctcs/ctcs.tar.bz2 delete mode 100644 client/tests/kvm/autotest_control/cerberus.control create mode 100644 client/tests/kvm/autotest_control/ctcs.control -- 1.7.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
[PATCH 2/2] KVM test: Update ctcs run on guests
Just update the config file and the control file that is supposed to run on guests. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/autotest_control/cerberus.control | 20 client/tests/kvm/autotest_control/ctcs.control | 19 +++ client/tests/kvm/tests_base.cfg.sample |4 ++-- 3 files changed, 21 insertions(+), 22 deletions(-) delete mode 100644 client/tests/kvm/autotest_control/cerberus.control create mode 100644 client/tests/kvm/autotest_control/ctcs.control diff --git a/client/tests/kvm/autotest_control/cerberus.control b/client/tests/kvm/autotest_control/cerberus.control deleted file mode 100644 index 5a828f0..000 --- a/client/tests/kvm/autotest_control/cerberus.control +++ /dev/null @@ -1,20 +0,0 @@ -AUTHOR = -Manas Kumar Nayak (makna...@in.ibm.com) (original code) -Lucas Meneghel Rodrigues (luca...@br.ibm.com) (rewrite) -Cao, Chen k...@redhat.com (use ctcs2 and port it to 64) - -NAME = Cerberus test suite -TEST_TYPE = CLIENT -TEST_CLASS = HARDWARE -TEST_CATEGORY = BENCHMARK -TIME = MEDIUM -DOC = \ -Executes the cerberus test for a period of time specified. You -can also provide a cerberus test control file of your own, trough the parameter -tcf_contents. - -see http://sourceforge.net/projects/ctcs2 -and http://sourceforge.net/projects/va-ctcs - - -job.run_test(url='cerberus', length='1h', tc_opt='-k -C -a') diff --git a/client/tests/kvm/autotest_control/ctcs.control b/client/tests/kvm/autotest_control/ctcs.control new file mode 100644 index 000..c105344 --- /dev/null +++ b/client/tests/kvm/autotest_control/ctcs.control @@ -0,0 +1,19 @@ +AUTHOR = +Manas Kumar Nayak (makna...@in.ibm.com) (original code) +Lucas Meneghel Rodrigues (luca...@br.ibm.com) (rewrite) +Cao, Chen k...@redhat.com (use ctcs2 and port it to 64) +Lucas Meneghel Rodrigues (l...@redhat.com) (use ctcs new source repo) + +NAME = CTCS +TEST_TYPE = CLIENT +TEST_CLASS = HARDWARE +TEST_CATEGORY = BENCHMARK +TIME = MEDIUM +DOC = +Executes CTCS for a period of time specified. You can also provide a cerberus +test control file of your own, trough the parameter tcf_contents. + +see https://github.com/autotest/ctcs + + +job.run_test(url='ctcs', length='1h', tc_opt='-k -C -a') diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index d3597b4..3b69b37 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -233,11 +233,11 @@ variants: test_control_file = stress.control - disktest: test_control_file = disktest.control -- ctcs2: +- ctcs: # If you think this is too lengthy, please change the cerberus # control file and set this timeout appropriately. test_timeout = 3900 -test_control_file = cerberus.control +test_control_file = ctcs.control - npb: test_control_file = npb.control - hackbench: -- 1.7.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: Livebackup feature for qemu/qemu-kvm
On 05/03/11 07:58, Jagane Sundar wrote: On 5/2/2011 7:36 AM, Jes Sorensen wrote: Reading your page, the first thing I stumble upon under 'Use Cases' is the reference to EBS storage. What is that? EBS stands for Elastic Block Storage - Amazon EC2's shared storage solution. This is the storage that comes with guarantees, since it is replicated across machines. I see, it would be good if you made that more explicit in the document for those who aren't as experienced with EC2, like me. Under details, I think it is not a good idea to rely on QEMU looking for any files with specific file name suffixes. It really should be specified on the command line by the user or admin tool. That's a good idea. Perhaps another attribute in the drive description list, just like type=virtio, maybe backup=livebackup. I think that is the right way to go. In general it looks interesting, you could consider submitting a presentation about Livebackup to the KVM Forum 2011. Glad to know that you think it is interesting. Also, thanks for the pointer to KVM Forum 2011, Jes. It looks like I have a few more weeks to get an abstract in for KVM forum 2011. I will do so. Excellent, please go ahead and submit it! Cheers, 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: Livebackup feature for qemu/qemu-kvm
On 5/2/2011 11:59 PM, Jes Sorensen wrote: On 05/03/11 07:58, Jagane Sundar wrote: On 5/2/2011 7:36 AM, Jes Sorensen wrote: Reading your page, the first thing I stumble upon under 'Use Cases' is the reference to EBS storage. What is that? EBS stands for Elastic Block Storage - Amazon EC2's shared storage solution. This is the storage that comes with guarantees, since it is replicated across machines. I see, it would be good if you made that more explicit in the document for those who aren't as experienced with EC2, like me. Done. I also added a failure scenarios section. I will ping you once I get the synopsis in for kvm forum 2011. 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: [CentOS] Install CentOS as KVM guest
On Sat, Apr 30, 2011 at 03:47:50AM +0800, Emmanuel Noobadmin wrote: On 4/29/11, Emmanuel Noobadmin centos.ad...@gmail.com wrote: Only problem is... networking still isn't working although brctl show on the host shows that a vnet0 had been created and attached to the bridge. Any pointers would be appreciated! Just to close off on this issue for the benefit of any future clueless newbies like me, networking wasn't working due to one missing element in the .xml model type='virtio' / was the missing ingredient. Thanks you for digging dipper. I am sure this shouldn't be so complicated though. Can you share you experience with libvirt team? http://libvirt.org/contact.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: nmi is broken?
On 05/02/2011 05:30 PM, OGAWA Hirofumi wrote: So, I think there are some solutions, a) current behavior is right (I don't know why it's right though), b) fix the behavior of IO-APIC and MADT like you said, then linux can detect it, c) change the model to like mpspec figure 5-2, d) other. My suggestion is c) if there is no good d). Because current behavior looks like almost c), and non-legacy chipsets are using c) model as far as I know. You're probably right. However we can't just change it, we need to make it an option, keeping the current configuration as the default. This is so that live migration can work, and because 5-2 requires a new kernel/user interface, to set IMCR.E0. Looking at figures 3-3 and 3-4 of the mpspec, the current model supports 3-3 but not 3-4. Do we report that IMCR exists in the mptables? I don't think we have to implement IMCR, because it seems to be an optional. In fact, physical hardwares which I have don't report IMCR in mptables. (I don't see the benefit to implement it on recent chipsets even if it's possible. The virtual wire mode seems to be enough.) Okay. I don't know about live migration of kvm. If we said the wiring is like figure 5-2, what is required for the live migration? It was required only if IMCR was required? The issue with live migration is that we can't change the running configuration while the system is running, like adding the IMCR or changing the wiring. The hardware will be programmed for the old configuration and will likely fail with the new one. For example, the current wiring has the PIT output wired to PIC IRQ0 and IOAPIC INTI0; we need to change it to IOAPIC INTI2 instead. -- 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: nmi is broken?
On 04/24/2011 05:08 PM, Jan Kiszka wrote:
On 2011-04-24 08:44, Avi Kivity wrote:
On 04/24/2011 01:50 AM, OGAWA Hirofumi wrote:
OGAWA Hirofumihirof...@mail.parknet.co.jp writes:
I noticed recently NMI on guest kernel is not working well.
host/guest
kernel is 2.6.39-rc4, and using vmx.
And test code is something like the following:
local_irq_disable();
for (i = 0; i 10; i++) {
int cpu = get_cpu();
printk(%s: nmi %u, lapic %u\n, __FUNCTION__,
nmi_count(cpu), irq_stat[cpu].apic_timer_irqs);
mdelay(1000);
put_cpu();
}
the result is both of nmi and lapic are not increased. If I used
-no-kvm-irqchip, it works fine (increase nmi only). So, it seems to be
the bug of kvm driver side.
With some debug, the cause seems to be in pit_do_work(). With the
following patch, NMI watchdog seems to be working correctly (if irq
disabled for long time, NMI watchdog can detect it).
Is the following patch right?
This would cause IRQs to be delivered even if the PIT is masked, no?
Are you in fact using the PIT? Linux prefers the HPET, and in my
experience the -no-hpet option makes NMIs work.
BTW, that's another bug of the in-kernel PIT model: It disables the
timer in HPET legacy mode even if we are aware of NMI watchdog
receivers. Actually, the whole legacy disabling looks a bit strange in
the PIT (mode hackery + flag testing...).
While this should be fixed/refactored, adding basic perf support to KVM
will be the only option long-term as Linux dropped virtual-wire NMI
watchdog support some releases ago.
Yes. Unfortunately that is very vendor and model specific. The
architectural PMU is supported, but that is only available on Intel.
Perhaps we could emulate the architectural PMU on AMD as well, and make
the detection code in the guest vendor agnostic. Since it's based on a
cpuid bit, it should be safe.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
Blue Swirl wrote: On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov g...@redhat.com wrote: On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote: On 04/07/2011 02:17 PM, Gleb Natapov wrote: On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote: On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapovg...@redhat.com wrote: I'd prefer something more generic like these: raise /apic@fee0:l1int lower /i44FX-pcihost/e1000@03.0/pinD The clumsier syntax shouldn't be a problem, since this would be a system developer tool. Some kind of IRQ registration would be needed for this to work without lots of changes. True. The ability to trigger any interrupt line is very useful for debugging. I often re-implement it during debug. And it's a good thing to have, but exposing this as the only API to do something as simple as generating a guest crash dump is not the friendliest thing in the world to do to users. Well, this is not intended to be used by regular users directly and management can provide nicer interface for issuing NMI. But really, my point is that NMI actually generates guest core dump in such rare cases (only preconfigured Windows guests) that it doesn't warrant to name command as such. Management is in much better position to implement functionality with such name since it knows what type of guest it runs and can tell agent to configure guest accordingly. Does the management need to know about each and every debugging oriented interface? For example, info regs, info mem, info irq and tracepoints? Linux uses NMI for performance tracing, profiling, watchdog etc. so in practice, NMI is very similar to the other IRQs. I.e. highly guest specific and depending on what's wired up to it. Injecting NMI to all CPUs at once does not make any sense for those Linux guests. For Windows crash dumps, I think it makes sense to have a button wired to NMI device, rather than inject-nmi directly, but I can see that inject-nmi solves the intended problem quite neatly. For Linux crash dumps, for example, there are other key combinations, as well as watchdog devices, that can be used to trigger them. A virtual button wired to GPIO/PCI-IRQ/etc. device might be quite handy for debugging Linux guests, and would fit comfortably in a management interface. -- Jamie -- 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: nmi is broken?
On 05/03/2011 12:36 PM, Avi Kivity wrote: I don't know about live migration of kvm. If we said the wiring is like figure 5-2, what is required for the live migration? It was required only if IMCR was required? The issue with live migration is that we can't change the running configuration while the system is running, like adding the IMCR or changing the wiring. The hardware will be programmed for the old configuration and will likely fail with the new one. For example, the current wiring has the PIT output wired to PIC IRQ0 and IOAPIC INTI0; we need to change it to IOAPIC INTI2 instead. btw, I believe that the configuration currently implemented is legal (it's similar to config 7 in table 5-2 of the mpspec); the only problem is that it can't support the NMI watchdog through the I/O APIC trick, yet we allow it through a hack. Something we can do is connect the 8259A output to the I/O APIC INTIN2; it should be masked so live migration will continue to work. We just have to make sure that the guest is able to find that it is connected there. -- 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
KVM call agenda for May 03rd
Please send in any agenda items you are interested in covering. 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
Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
Gleb Natapov wrote: On Thu, Apr 07, 2011 at 04:39:58PM -0500, Anthony Liguori wrote: On 04/07/2011 01:51 PM, Gleb Natapov wrote: NMI does not have to generate crash dump on every guest we support. Actually even for windows guest it does not generate one without tweaking registry. For all I know there is a guest that checks mail when NMI arrives. And for all we know, a guest can respond to an ACPI poweroff event by tweeting the star spangled banner but we still call the corresponding QMP command system_poweroff. Correct :) But at least system_poweroff implements ACPI poweroff as defined by ACPI spec. NMI is not designed as core dump event and is not used as such by majority of the guests. Imho acpi_poweroff or poweroff_button would have been a clearer name. Or even 'sendkey poweroff' - it's just a button someone on the keyboard on a lot of systems anyway. Next to the email button and what looks, on my laptop, like the play-a-tune button :-) I put system_poweroff into some QEMU-controlling scripts once, and was disappointed when several guests ignored it. But it's done now. -- Jamie -- 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: nmi is broken?
On 2011-05-03 11:43, Avi Kivity wrote:
On 04/24/2011 05:08 PM, Jan Kiszka wrote:
On 2011-04-24 08:44, Avi Kivity wrote:
On 04/24/2011 01:50 AM, OGAWA Hirofumi wrote:
OGAWA Hirofumihirof...@mail.parknet.co.jp writes:
I noticed recently NMI on guest kernel is not working well.
host/guest
kernel is 2.6.39-rc4, and using vmx.
And test code is something like the following:
local_irq_disable();
for (i = 0; i 10; i++) {
int cpu = get_cpu();
printk(%s: nmi %u, lapic %u\n, __FUNCTION__,
nmi_count(cpu), irq_stat[cpu].apic_timer_irqs);
mdelay(1000);
put_cpu();
}
the result is both of nmi and lapic are not increased. If I used
-no-kvm-irqchip, it works fine (increase nmi only). So, it
seems to be
the bug of kvm driver side.
With some debug, the cause seems to be in pit_do_work(). With the
following patch, NMI watchdog seems to be working correctly (if irq
disabled for long time, NMI watchdog can detect it).
Is the following patch right?
This would cause IRQs to be delivered even if the PIT is masked, no?
Are you in fact using the PIT? Linux prefers the HPET, and in my
experience the -no-hpet option makes NMIs work.
BTW, that's another bug of the in-kernel PIT model: It disables the
timer in HPET legacy mode even if we are aware of NMI watchdog
receivers. Actually, the whole legacy disabling looks a bit strange in
the PIT (mode hackery + flag testing...).
While this should be fixed/refactored, adding basic perf support to KVM
will be the only option long-term as Linux dropped virtual-wire NMI
watchdog support some releases ago.
Yes. Unfortunately that is very vendor and model specific. The
architectural PMU is supported, but that is only available on Intel.
Is it supposed to have any practical value already? I did not yet find a
magic -cpu switch to let Linux detect anything, not to speak of perf or
watchdog support.
Perhaps we could emulate the architectural PMU on AMD as well, and make
the detection code in the guest vendor agnostic. Since it's based on a
cpuid bit, it should be safe.
We may only make Linux happy this way, no?
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] kvm: ppc: detect old headers
On 03.05.2011, at 14:31, Jan Kiszka wrote: On 2011-05-03 14:28, Alexander Graf wrote: On 03.05.2011, at 14:14, Jan Kiszka wrote: On 2011-05-03 13:54, Alexander Graf wrote: When compiling Qemu with older kernel headers, the PVR setting mechanism isn't available yet. Unfortunately, back then I didn't add a capability we could check against, so all we can do is add a configure test to see if we support PVR setting. For BookE, we don't care yet. This fixes compilation errors with KVM enabled on older kernel headers (like 2.6.32). Why not finally import the latest kvm kernel headers into qemu? Would save us a lot of current and future configure and #ifdef dances. Sure, sounds like a good topic for today's call? Fine with me. Patch should be done by then as well. *shrug* I'm fairly indifferent on that topic. It would help users, so they can easier compile things, but requires us to keep the headers in sync. Do you have any good way of automating the process? Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL 0/6] PPC KVM patches
Hi Marcelo / Avi, This is my current PPC KVM patch queue. Please pull. Alex The following changes since commit 40f4a244a3687d390e97f8e5240f5a701e630ccc: Avi Kivity (1): KVM: VMX: Cache vmcs segment fields are available in the git repository at: git://github.com/agraf/linux-2.6.git kvm-ppc-next Alexander Graf (1): KVM: PPC: Add kvm headers to headers_install Scott Wood (4): KVM: PPC: e500: emulate SVR KVM: PPC: fix exit accounting for SPRs, tlbwe, tlbsx KVM: PPC: booke: save/restore VRSAVE (a.k.a. USPRG0) KVM: PPC: booke: add sregs support Stuart Yoder (1): KVM: PPC: use ticks, not usecs, for exit timing Documentation/kvm/api.txt |6 +- arch/powerpc/include/asm/Kbuild |2 + arch/powerpc/include/asm/kvm.h | 184 +++ arch/powerpc/include/asm/kvm_44x.h |1 - arch/powerpc/include/asm/kvm_e500.h |2 + arch/powerpc/include/asm/kvm_host.h |4 + arch/powerpc/include/asm/kvm_ppc.h |9 ++ arch/powerpc/kernel/asm-offsets.c |1 + arch/powerpc/kvm/44x.c | 10 ++ arch/powerpc/kvm/44x_emulate.c |2 - arch/powerpc/kvm/booke.c| 154 +- arch/powerpc/kvm/booke_interrupts.S |1 - arch/powerpc/kvm/e500.c | 76 ++ arch/powerpc/kvm/e500_emulate.c |7 +- arch/powerpc/kvm/e500_tlb.c | 13 +++- arch/powerpc/kvm/emulate.c | 15 ++- arch/powerpc/kvm/powerpc.c | 17 +++ arch/powerpc/kvm/timing.c | 21 +++- include/linux/kvm.h |1 + 19 files changed, 505 insertions(+), 21 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 1/6] KVM: PPC: e500: emulate SVR
From: Scott Wood scottw...@freescale.com
Return the actual host SVR for now, as we already do for PVR. Eventually
we may support Qemu overriding PVR/SVR if the situation is appropriate,
once we implement KVM_SET_SREGS on e500.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm_e500.h |1 +
arch/powerpc/kvm/e500.c |1 +
arch/powerpc/kvm/e500_emulate.c |2 ++
3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_e500.h
b/arch/powerpc/include/asm/kvm_e500.h
index 7fea26f..bb2a089 100644
--- a/arch/powerpc/include/asm/kvm_e500.h
+++ b/arch/powerpc/include/asm/kvm_e500.h
@@ -43,6 +43,7 @@ struct kvmppc_vcpu_e500 {
u32 host_pid[E500_PID_NUM];
u32 pid[E500_PID_NUM];
+ u32 svr;
u32 mas0;
u32 mas1;
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index e3768ee..0c1af12 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -63,6 +63,7 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)
/* Registers init */
vcpu-arch.pvr = mfspr(SPRN_PVR);
+ vcpu_e500-svr = mfspr(SPRN_SVR);
/* Since booke kvm only support one core, update all vcpus' PIR to 0 */
vcpu-vcpu_id = 0;
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 8e3edfb..e2fb47f 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -175,6 +175,8 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
kvmppc_set_gpr(vcpu, rt, vcpu_e500-hid0); break;
case SPRN_HID1:
kvmppc_set_gpr(vcpu, rt, vcpu_e500-hid1); break;
+ case SPRN_SVR:
+ kvmppc_set_gpr(vcpu, rt, vcpu_e500-svr); break;
case SPRN_MMUCSR0:
kvmppc_set_gpr(vcpu, rt, 0); break;
--
1.6.0.2
--
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/6] KVM: PPC: use ticks, not usecs, for exit timing
From: Stuart Yoder stuart.yo...@freescale.com
Convert to microseconds when displaying
(with fix from Bharat Bhushan bharat.bhus...@freescale.com).
This reduces rounding error with large quantities of short exits.
Signed-off-by: Stuart Yoder stuart.yo...@freescale.com
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/timing.c | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
index 18f40fd..319177d 100644
--- a/arch/powerpc/kvm/timing.c
+++ b/arch/powerpc/kvm/timing.c
@@ -151,17 +151,30 @@ static int kvmppc_exit_timing_show(struct seq_file *m,
void *private)
{
struct kvm_vcpu *vcpu = m-private;
int i;
+ u64 min, max, sum, sum_quad;
seq_printf(m, %s, type count min max sum
sum_squared\n);
+
for (i = 0; i __NUMBER_OF_KVM_EXIT_TYPES; i++) {
+
+ min = vcpu-arch.timing_min_duration[i];
+ do_div(min, tb_ticks_per_usec);
+ max = vcpu-arch.timing_max_duration[i];
+ do_div(max, tb_ticks_per_usec);
+ sum = vcpu-arch.timing_sum_duration[i];
+ do_div(sum, tb_ticks_per_usec);
+ sum_quad = vcpu-arch.timing_sum_quad_duration[i];
+ do_div(sum_quad, tb_ticks_per_usec);
+
seq_printf(m, %12s %10d%10lld %10lld %20lld
%20lld\n,
kvm_exit_names[i],
vcpu-arch.timing_count_type[i],
- vcpu-arch.timing_min_duration[i],
- vcpu-arch.timing_max_duration[i],
- vcpu-arch.timing_sum_duration[i],
- vcpu-arch.timing_sum_quad_duration[i]);
+ min,
+ max,
+ sum,
+ sum_quad);
+
}
return 0;
}
--
1.6.0.2
--
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/6] KVM: PPC: Add kvm headers to headers_install
When running make headers_install, we don't install kvm headers on PPC. This confuses Qemu, as it really wants to include kernel headers to know the ioctl structs. So let's add the arch/powerpc/include/asm headers that are important for KVM to the headers_install list. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/include/asm/Kbuild |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index d51df17..568b000 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -34,3 +34,5 @@ header-y += termios.h header-y += types.h header-y += ucontext.h header-y += unistd.h +header-y += kvm.h +header-y += kvm_para.h -- 1.6.0.2 -- 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 4/6] KVM: PPC: booke: save/restore VRSAVE (a.k.a. USPRG0)
From: Scott Wood scottw...@freescale.com
Linux doesn't use USPRG0 (now renamed VRSAVE in the architecture, even
when Altivec isn't involved), but a guest might.
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm_host.h |1 +
arch/powerpc/kernel/asm-offsets.c |1 +
arch/powerpc/kvm/booke_interrupts.S |1 -
arch/powerpc/kvm/powerpc.c | 13 +
4 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 890897c..a168043 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -223,6 +223,7 @@ struct kvm_vcpu_arch {
ulong hflags;
ulong guest_owned_ext;
#endif
+ u32 vrsave; /* also USPRG0 */
u32 mmucr;
ulong sprg4;
ulong sprg5;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 23e6a93..cf0d822 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -395,6 +395,7 @@ int main(void)
DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, arch.host_stack));
DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, arch.host_pid));
DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
+ DEFINE(VCPU_VRSAVE, offsetof(struct kvm_vcpu, arch.vrsave));
DEFINE(VCPU_SPRG4, offsetof(struct kvm_vcpu, arch.sprg4));
DEFINE(VCPU_SPRG5, offsetof(struct kvm_vcpu, arch.sprg5));
DEFINE(VCPU_SPRG6, offsetof(struct kvm_vcpu, arch.sprg6));
diff --git a/arch/powerpc/kvm/booke_interrupts.S
b/arch/powerpc/kvm/booke_interrupts.S
index 1cc471f..b58ccae 100644
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -380,7 +380,6 @@ lightweight_exit:
* because host interrupt handlers would get confused. */
lwz r1, VCPU_GPR(r1)(r4)
- /* XXX handle USPRG0 */
/* Host interrupt handlers may have clobbered these guest-readable
* SPRGs, so we need to reload them here with the guest's values. */
lwz r3, VCPU_SPRG4(r4)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index ec3d2e7..9e6aa8b 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -298,12 +298,25 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
+#ifdef CONFIG_BOOKE
+ /*
+* vrsave (formerly usprg0) isn't used by Linux, but may
+* be used by the guest.
+*
+* On non-booke this is associated with Altivec and
+* is handled by code in book3s.c.
+*/
+ mtspr(SPRN_VRSAVE, vcpu-arch.vrsave);
+#endif
kvmppc_core_vcpu_load(vcpu, cpu);
}
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
{
kvmppc_core_vcpu_put(vcpu);
+#ifdef CONFIG_BOOKE
+ vcpu-arch.vrsave = mfspr(SPRN_VRSAVE);
+#endif
}
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
--
1.6.0.2
--
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 5/6] KVM: PPC: booke: add sregs support
From: Scott Wood scottw...@freescale.com
Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: Alexander Graf ag...@suse.de
---
Documentation/kvm/api.txt |6 +-
arch/powerpc/include/asm/kvm.h | 184 +++
arch/powerpc/include/asm/kvm_44x.h |1 -
arch/powerpc/include/asm/kvm_e500.h |1 +
arch/powerpc/include/asm/kvm_host.h |3 +
arch/powerpc/include/asm/kvm_ppc.h |9 ++
arch/powerpc/kvm/44x.c | 10 ++
arch/powerpc/kvm/booke.c| 154 +-
arch/powerpc/kvm/e500.c | 75 ++
arch/powerpc/kvm/e500_emulate.c |5 +-
arch/powerpc/kvm/e500_tlb.c |8 ++
arch/powerpc/kvm/emulate.c | 13 ++-
arch/powerpc/kvm/powerpc.c |4 +
include/linux/kvm.h |1 +
14 files changed, 461 insertions(+), 13 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 1b9eaa7..f64c41f 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -261,7 +261,7 @@ See KVM_GET_REGS for the data structure.
4.13 KVM_GET_SREGS
Capability: basic
-Architectures: x86
+Architectures: x86, ppc
Type: vcpu ioctl
Parameters: struct kvm_sregs (out)
Returns: 0 on success, -1 on error
@@ -279,6 +279,8 @@ struct kvm_sregs {
__u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
};
+/* ppc -- see arch/powerpc/include/asm/kvm.h */
+
interrupt_bitmap is a bitmap of pending external interrupts. At most
one bit may be set. This interrupt has been acknowledged by the APIC
but not yet injected into the cpu core.
@@ -286,7 +288,7 @@ but not yet injected into the cpu core.
4.14 KVM_SET_SREGS
Capability: basic
-Architectures: x86
+Architectures: x86, ppc
Type: vcpu ioctl
Parameters: struct kvm_sregs (in)
Returns: 0 on success, -1 on error
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 18ea696..d2ca5ed 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -45,6 +45,114 @@ struct kvm_regs {
__u64 gpr[32];
};
+#define KVM_SREGS_E_IMPL_NONE 0
+#define KVM_SREGS_E_IMPL_FSL 1
+
+#define KVM_SREGS_E_FSL_PIDn (1 0) /* PID1/PID2 */
+
+/*
+ * Feature bits indicate which sections of the sregs struct are valid,
+ * both in KVM_GET_SREGS and KVM_SET_SREGS. On KVM_SET_SREGS, registers
+ * corresponding to unset feature bits will not be modified. This allows
+ * restoring a checkpoint made without that feature, while keeping the
+ * default values of the new registers.
+ *
+ * KVM_SREGS_E_BASE contains:
+ * CSRR0/1 (refers to SRR2/3 on 40x)
+ * ESR
+ * DEAR
+ * MCSR
+ * TSR
+ * TCR
+ * DEC
+ * TB
+ * VRSAVE (USPRG0)
+ */
+#define KVM_SREGS_E_BASE (1 0)
+
+/*
+ * KVM_SREGS_E_ARCH206 contains:
+ *
+ * PIR
+ * MCSRR0/1
+ * DECAR
+ * IVPR
+ */
+#define KVM_SREGS_E_ARCH206(1 1)
+
+/*
+ * Contains EPCR, plus the upper half of 64-bit registers
+ * that are 32-bit on 32-bit implementations.
+ */
+#define KVM_SREGS_E_64 (1 2)
+
+#define KVM_SREGS_E_SPRG8 (1 3)
+#define KVM_SREGS_E_MCIVPR (1 4)
+
+/*
+ * IVORs are used -- contains IVOR0-15, plus additional IVORs
+ * in combination with an appropriate feature bit.
+ */
+#define KVM_SREGS_E_IVOR (1 5)
+
+/*
+ * Contains MAS0-4, MAS6-7, TLBnCFG, MMUCFG.
+ * Also TLBnPS if MMUCFG[MAVN] = 1.
+ */
+#define KVM_SREGS_E_ARCH206_MMU(1 6)
+
+/* DBSR, DBCR, IAC, DAC, DVC */
+#define KVM_SREGS_E_DEBUG (1 7)
+
+/* Enhanced debug -- DSRR0/1, SPRG9 */
+#define KVM_SREGS_E_ED (1 8)
+
+/* Embedded Floating Point (SPE) -- IVOR32-34 if KVM_SREGS_E_IVOR */
+#define KVM_SREGS_E_SPE(1 9)
+
+/* External Proxy (EXP) -- EPR */
+#define KVM_SREGS_EXP (1 10)
+
+/* External PID (E.PD) -- EPSC/EPLC */
+#define KVM_SREGS_E_PD (1 11)
+
+/* Processor Control (E.PC) -- IVOR36-37 if KVM_SREGS_E_IVOR */
+#define KVM_SREGS_E_PC (1 12)
+
+/* Page table (E.PT) -- EPTCFG */
+#define KVM_SREGS_E_PT (1 13)
+
+/* Embedded Performance Monitor (E.PM) -- IVOR35 if KVM_SREGS_E_IVOR */
+#define KVM_SREGS_E_PM (1 14)
+
+/*
+ * Special updates:
+ *
+ * Some registers may change even while a vcpu is not running.
+ * To avoid losing these changes, by default these registers are
+ * not updated by KVM_SET_SREGS. To force an update, set the bit
+ * in u.e.update_special corresponding to the register to be updated.
+ *
+ * The update_special field is zero on return from KVM_GET_SREGS.
+ *
+ * When restoring a checkpoint, the caller can set update_special
+ * to 0x to ensure that everything is restored, even new features
+ * that the caller doesn't know about.
+ */
+#define KVM_SREGS_E_UPDATE_MCSR(1 0)
+#define KVM_SREGS_E_UPDATE_TSR (1 1)
+#define
[PATCH 2/6] KVM: PPC: fix exit accounting for SPRs, tlbwe, tlbsx
From: Scott Wood scottw...@freescale.com The exit type setting for mfspr/mtspr is moved from 44x to toplevel SPR emulation. This enables it on e500, and makes sure that all SPRs are covered. Exit accounting for tlbwe and tlbsx is added to e500. Signed-off-by: Stuart Yoder stuart.yo...@freescale.com Signed-off-by: Scott Wood scottw...@freescale.com Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/kvm/44x_emulate.c |2 -- arch/powerpc/kvm/e500_tlb.c|5 - arch/powerpc/kvm/emulate.c |2 ++ 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kvm/44x_emulate.c b/arch/powerpc/kvm/44x_emulate.c index 65ea083..549bb2c 100644 --- a/arch/powerpc/kvm/44x_emulate.c +++ b/arch/powerpc/kvm/44x_emulate.c @@ -158,7 +158,6 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs) emulated = kvmppc_booke_emulate_mtspr(vcpu, sprn, rs); } - kvmppc_set_exit_type(vcpu, EMULATED_MTSPR_EXITS); return emulated; } @@ -179,7 +178,6 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt) emulated = kvmppc_booke_emulate_mfspr(vcpu, sprn, rt); } - kvmppc_set_exit_type(vcpu, EMULATED_MFSPR_EXITS); return emulated; } diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c index d6d6d47..56ac452 100644 --- a/arch/powerpc/kvm/e500_tlb.c +++ b/arch/powerpc/kvm/e500_tlb.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2008 Freescale Semiconductor, Inc. All rights reserved. + * Copyright (C) 2008-2011 Freescale Semiconductor, Inc. All rights reserved. * * Author: Yu Liu, yu@freescale.com * @@ -24,6 +24,7 @@ #include ../mm/mmu_decl.h #include e500_tlb.h #include trace.h +#include timing.h #define to_htlb1_esel(esel) (tlb1_entry_num - (esel) - 1) @@ -506,6 +507,7 @@ int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, int rb) vcpu_e500-mas7 = 0; } + kvmppc_set_exit_type(vcpu, EMULATED_TLBSX_EXITS); return EMULATE_DONE; } @@ -571,6 +573,7 @@ int kvmppc_e500_emul_tlbwe(struct kvm_vcpu *vcpu) write_host_tlbe(vcpu_e500, stlbsel, sesel); } + kvmppc_set_exit_type(vcpu, EMULATED_TLBWE_EXITS); return EMULATE_DONE; } diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c index c64fd29..8f7a3aa 100644 --- a/arch/powerpc/kvm/emulate.c +++ b/arch/powerpc/kvm/emulate.c @@ -294,6 +294,7 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct kvm_vcpu *vcpu) } break; } + kvmppc_set_exit_type(vcpu, EMULATED_MFSPR_EXITS); break; case OP_31_XOP_STHX: @@ -363,6 +364,7 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct kvm_vcpu *vcpu) printk(mtspr: unknown spr %x\n, sprn); break; } + kvmppc_set_exit_type(vcpu, EMULATED_MTSPR_EXITS); break; case OP_31_XOP_DCBI: -- 1.6.0.2 -- 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: ppc: detect old headers
On 2011-05-03 14:33, Alexander Graf wrote: On 03.05.2011, at 14:31, Jan Kiszka wrote: On 2011-05-03 14:28, Alexander Graf wrote: On 03.05.2011, at 14:14, Jan Kiszka wrote: On 2011-05-03 13:54, Alexander Graf wrote: When compiling Qemu with older kernel headers, the PVR setting mechanism isn't available yet. Unfortunately, back then I didn't add a capability we could check against, so all we can do is add a configure test to see if we support PVR setting. For BookE, we don't care yet. This fixes compilation errors with KVM enabled on older kernel headers (like 2.6.32). Why not finally import the latest kvm kernel headers into qemu? Would save us a lot of current and future configure and #ifdef dances. Sure, sounds like a good topic for today's call? Fine with me. Patch should be done by then as well. *shrug* I'm fairly indifferent on that topic. It would help users, so they can easier compile things, but requires us to keep the headers in sync. Do you have any good way of automating the process? There will be a 'make update-kvm-headers' target, imported from kvm-kmod. Can be run against some recent kernel, and the result will just have to be committed posted. Moreover, I will drop alternative ways of pulling in headers (except via CFLAGS overwriting). That will typically bite the patch submitter who requires a header update and make her/him submit latest headers as well. So far at least for the theory. 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 call agenda for May 03rd
On 2011-05-03 12:21, Juan Quintela wrote: Please send in any agenda items you are interested in covering. Provided there will be more topics: - import kvm headers into qemu, drop #ifdef maze Otherwise, we can also discuss this based on the patch I'm preparing ATM. 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: [Qemu-devel] KVM call agenda for May 03rd
On 05/03/2011 08:04 AM, Jan Kiszka wrote: On 2011-05-03 12:21, Juan Quintela wrote: Please send in any agenda items you are interested in covering. Provided there will be more topics: - import kvm headers into qemu, drop #ifdef maze This has come up a few times in the past. The opposition tends to be that it would make feature development harder because you couldn't easily point QEMU at a different set of kernel headers. These days, so few things change in the KVM interface though that maybe it's not the end of the world. Regards, Anthony Liguori Otherwise, we can also discuss this based on the patch I'm preparing ATM. 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: [PATCH 2/2] KVM: make guest mode entry to be rcu quiescent state
Hi Gleb,
Thats a neat idea.
On Thu, Apr 28, 2011 at 12:52:03PM +0300, Gleb Natapov wrote:
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). Lets treat
guest mode as quiescent state, just like we do with user-mode execution.
Signed-off-by: Gleb Natapov g...@redhat.com
---
include/linux/kvm_host.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 0bc3d37..a347bce 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -593,6 +593,7 @@ static inline void kvm_guest_enter(void)
{
account_system_vtime(current);
current-flags |= PF_VCPU;
+ rcu_note_context_switch(smp_processor_id());
}
static inline void kvm_guest_exit(void)
--
1.7.2.3
Please have it in x86's vcpu_enter_guest, then its more explicit
(uncertain about the context of kvm_guest_enter call in other arches).
--
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 2/2] KVM: make guest mode entry to be rcu quiescent state
On 05/03/2011 04:13 PM, Marcelo Tosatti wrote: Please have it in x86's vcpu_enter_guest, then its more explicit (uncertain about the context of kvm_guest_enter call in other arches). We do need it for other archs, don't we? -- 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 2/2] KVM: make guest mode entry to be rcu quiescent state
On Tue, May 03, 2011 at 10:13:17AM -0300, Marcelo Tosatti wrote:
Hi Gleb,
Thats a neat idea.
On Thu, Apr 28, 2011 at 12:52:03PM +0300, Gleb Natapov wrote:
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). Lets treat
guest mode as quiescent state, just like we do with user-mode execution.
Signed-off-by: Gleb Natapov g...@redhat.com
---
include/linux/kvm_host.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 0bc3d37..a347bce 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -593,6 +593,7 @@ static inline void kvm_guest_enter(void)
{
account_system_vtime(current);
current-flags |= PF_VCPU;
+ rcu_note_context_switch(smp_processor_id());
}
static inline void kvm_guest_exit(void)
--
1.7.2.3
Please have it in x86's vcpu_enter_guest, then its more explicit
(uncertain about the context of kvm_guest_enter call in other arches).
I checked all of them and kvm_guest_enter() is always called with local
irq disabled. Paul confirmed that rcu_note_context_switch() can be
called in such context.
--
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: nmi is broken?
Avi Kivity a...@redhat.com writes: On 05/03/2011 12:36 PM, Avi Kivity wrote: I don't know about live migration of kvm. If we said the wiring is like figure 5-2, what is required for the live migration? It was required only if IMCR was required? The issue with live migration is that we can't change the running configuration while the system is running, like adding the IMCR or changing the wiring. The hardware will be programmed for the old configuration and will likely fail with the new one. For example, the current wiring has the PIT output wired to PIC IRQ0 and IOAPIC INTI0; we need to change it to IOAPIC INTI2 instead. btw, I believe that the configuration currently implemented is legal (it's similar to config 7 in table 5-2 of the mpspec); the only problem is that it can't support the NMI watchdog through the I/O APIC trick, yet we allow it through a hack. I'm confused a bit. config 7 in table 5-2 says PIT output wired to IOAPIC INTIN2. So, we don't need to change it? Something we can do is connect the 8259A output to the I/O APIC INTIN2; it should be masked so live migration will continue to work. We just have to make sure that the guest is able to find that it is connected there. 8259A INTR to IOAPIC INTIN2 sounds strange. Isn't it IOAPIC INTIN0? Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp -- 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
[Bug 34282] New: general protection fault when starting virtual machine with qemu
https://bugzilla.kernel.org/show_bug.cgi?id=34282 Summary: general protection fault when starting virtual machine with qemu Product: Virtualization Version: unspecified Kernel Version: 2.6.38 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: kvm AssignedTo: virtualization_...@kernel-bugs.osdl.org ReportedBy: ricardo.wur...@gmail.com Regression: No A general protection fault occurs when running qemu-kvm on a qcow2 image (holding an installation of WinXP). The problem happens whenever the following command is executed: qemu-kvm \ -snapshot \ /path/to/image.qcow2 \ -net nic,model=e1000 -net user,hostname=host,hostfwd=tcp:3389-:3398 \ -m 384 \ -monitor unix:/tmp/kvm_console,server,nowait \ -usb \ -nographic Almost immediately after issuing the command, the trace (see below) is printed on the screen. The system doesn't go down (switching VTs clears the message from the screen), but qemu-kvm cannot be aborted from the terminal window in which it was launched. My system is running the latest kernel packaged for Arch Linux. $ uname -a Linux jingles 2.6.38-ARCH #1 SMP PREEMPT Fri Apr 22 17:48:36 UTC 2011 i686 AMD Phenom(tm) II X4 940 Processor AuthenticAMD GNU/Linux $ pacman -Qi qemu-kvm Name : qemu-kvm Version: 0.14.0-1 snip Architecture : i686 I'm running i686 linux on x86_64 hardware. This is the message + trace: [69862.239933] general protection fault: [#1] PREEMPT SMP [69862.240031] last sysfs file: /sys/devices/pci:00/:00:14.1/host4/uevent [69862.240136] Modules linked in: snd_seq_midi snd_hrtimer cpufreq_ondemand nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 ext3 jbd jfs joydev usbhid hid snd_usb_audio snd_usbmidi_lib radeon wacom snd_hda_codec_hdmi snd_hda_codec_realtek ttm drm_kms_helper drm agpgart ppdev snd_ice1724 snd_rawmidi snd_ice17xx_ak4xxx snd_ac97_codec ac97_bus snd_ak4xxx_adda snd_ak4114 snd_pt2258 snd_i2c powernow_k8 lp freq_table snd_hda_intel sp5100_tco snd_hda_codec evdev i2c_algo_bit snd_ak4113 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device firewire_ohci ohci_hcd i2c_piix4 shpchp snd_pcm_oss snd_hwdep snd_mixer_oss snd_pcm snd_timer floppy parport_pc mperf pcspkr r8169 ehci_hcd pci_hotplug snd parport firewire_core k10temp usbcore processor button i2c_core wmi mii kvm_amd soundcore snd_page_alloc serio_raw sg crc_itu_t kvm ext2 mbcache sr_mod cdrom sd_mod pata_acpi pata_atiixp ahci libahci libata scsi_mod [69862.241531] [69862.241554] Pid: 3738, comm: qemu-kvm Not tainted 2.6.38-ARCH #1 Gigabyte Technology Co., Ltd. GA-MA78GM-US2H/GA-MA78GM-US2H [69862.241725] EIP: 0060:[c118e11e] EFLAGS: 00210202 CPU: 2 [69862.241806] EIP is at submit_bio+0xe/0x100 [69862.241870] EAX: 0001 EBX: ed6be480 ECX: EDX: ed6be480 [69862.241959] ESI: ed6be480 EDI: 0001 EBP: cbde778c ESP: cbde773c [69862.242049] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [69862.242127] Process qemu-kvm (pid: 3738, ti=cbde6000 task=cbfae780 task.ti=cbde6000) [69862.242240] Stack: [69862.242269] 0010 0006 ef940be0 0029 f5d075ac c1451200 ef2827a8 ed6be480 [69862.242399] ed6be480 cbde7784 c112f2bb f1594bb4 0010 0001 000f ef2827a8 [69862.242527] ef2827a8 ef2827a8 cbde778c c112f38e cbde77a0 c112a76c ef2827a8 ef2827a8 [69862.242656] Call Trace: [69862.242695] [c112f2bb] ? bio_alloc_bioset+0x3b/0xc0 [69862.242770] [c112f38e] ? bio_alloc+0xe/0x20 [69862.242835] [c112a76c] submit_bh+0xcc/0xf0 [69862.242898] [c112c1e3] __block_write_full_page+0x223/0x380 [69862.242982] [c10fcfe8] ? memcg_check_events+0x28/0x160 [69862.243040] [f823ed70] ? ext2_get_block+0x0/0x800 [ext2] [69862.243040] [c112c3de] block_write_full_page_endio+0x9e/0xe0 [69862.243040] [c112aea0] ? end_buffer_async_write+0x0/0x1b0 [69862.243040] [f823ed70] ? ext2_get_block+0x0/0x800 [ext2] [69862.243040] [c112c432] block_write_full_page+0x12/0x20 [69862.243040] [c112aea0] ? end_buffer_async_write+0x0/0x1b0 [69862.243040] [f823e80f] ext2_writepage+0xf/0x20 [ext2] [69862.243040] [c10cc942] shrink_page_list+0x532/0x760 [69862.243040] [c10fe303] ? mem_cgroup_del_lru_list+0x23/0xa0 [69862.243040] [c10ccea2] shrink_inactive_list+0xf2/0x3f0 [69862.243040] [c10cd61c] shrink_zone+0x47c/0x5c0 [69862.243040] [c10cdff2] do_try_to_free_pages+0xb2/0x370 [69862.243040] [c10ce506] try_to_free_pages+0x76/0x150 [69862.243040] [c10c53d0] __alloc_pages_nodemask+0x420/0x750 [69862.243040] [c10faa57] do_huge_pmd_anonymous_page+0x107/0x2d0 [69862.243040] [f82cb96b] ? update_spte+0x8b/0x1a0 [kvm] [69862.243040] [c10dd12e] handle_mm_fault+0x17e/0x200 [69862.243040] [c10dd2c7] __get_user_pages+0x117/0x3d0 [69862.243040] [c10dd637] get_user_pages+0x57/0x70 [69862.243040] [c102ae0f] get_user_pages_fast+0xef/0x150 [69862.243040] [f82b22a9]
Re: nmi is broken?
On 05/03/2011 01:37 PM, Jan Kiszka wrote: Yes. Unfortunately that is very vendor and model specific. The architectural PMU is supported, but that is only available on Intel. Is it supposed to have any practical value already? I did not yet find a magic -cpu switch to let Linux detect anything, not to speak of perf or watchdog support. On the guest side it is supported for the watchdog (arch/x86/kernel/cpu/perfctr-watchdog.c, look for X86_FEATURE_ARCH_PERFMON). It's also mentioned in perf_event_intel.c, but I don't know if it will work without the other PMU features being present. Perhaps we could emulate the architectural PMU on AMD as well, and make the detection code in the guest vendor agnostic. Since it's based on a cpuid bit, it should be safe. We may only make Linux happy this way, no? I would argue that if a feature is discoverable by a cpuid bit it shouldn't need to be qualified by vendor. No idea how other OSes work this out (or even if they make use of the architectural PMU). -- 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 2/2] KVM: make guest mode entry to be rcu quiescent state
On Tue, May 03, 2011 at 04:21:23PM +0300, Gleb Natapov wrote:
On Tue, May 03, 2011 at 10:13:17AM -0300, Marcelo Tosatti wrote:
Hi Gleb,
Thats a neat idea.
On Thu, Apr 28, 2011 at 12:52:03PM +0300, Gleb Natapov wrote:
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). Lets treat
guest mode as quiescent state, just like we do with user-mode execution.
Signed-off-by: Gleb Natapov g...@redhat.com
---
include/linux/kvm_host.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 0bc3d37..a347bce 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -593,6 +593,7 @@ static inline void kvm_guest_enter(void)
{
account_system_vtime(current);
current-flags |= PF_VCPU;
+ rcu_note_context_switch(smp_processor_id());
}
static inline void kvm_guest_exit(void)
--
1.7.2.3
Please have it in x86's vcpu_enter_guest, then its more explicit
(uncertain about the context of kvm_guest_enter call in other arches).
I checked all of them and kvm_guest_enter() is always called with local
irq disabled. Paul confirmed that rcu_note_context_switch() can be
called in such context.
OK then. Perhaps have an assert to verify interrupts are disabled?
--
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: nmi is broken?
On 05/03/2011 04:25 PM, OGAWA Hirofumi wrote: Avi Kivitya...@redhat.com writes: On 05/03/2011 12:36 PM, Avi Kivity wrote: I don't know about live migration of kvm. If we said the wiring is like figure 5-2, what is required for the live migration? It was required only if IMCR was required? The issue with live migration is that we can't change the running configuration while the system is running, like adding the IMCR or changing the wiring. The hardware will be programmed for the old configuration and will likely fail with the new one. For example, the current wiring has the PIT output wired to PIC IRQ0 and IOAPIC INTI0; we need to change it to IOAPIC INTI2 instead. btw, I believe that the configuration currently implemented is legal (it's similar to config 7 in table 5-2 of the mpspec); the only problem is that it can't support the NMI watchdog through the I/O APIC trick, yet we allow it through a hack. I'm confused a bit. config 7 in table 5-2 says PIT output wired to IOAPIC INTIN2. So, we don't need to change it? We're like config 7 in that the 8259A output isn't wired to the IOAPIC. However we're unlike config 7 in that the PIT output is wired to IOAPIC INTIN0. I think we can keep it that way. Something we can do is connect the 8259A output to the I/O APIC INTIN2; it should be masked so live migration will continue to work. We just have to make sure that the guest is able to find that it is connected there. 8259A INTR to IOAPIC INTIN2 sounds strange. Isn't it IOAPIC INTIN0? Usually yes, but we already have the PIT wired to INTIN0. I saw that the kernel consults the mptable to see which pin to use, so with the right BIOS magic we can get things to work. -- 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 2/2] KVM: make guest mode entry to be rcu quiescent state
On Tue, May 03, 2011 at 10:29:52AM -0300, Marcelo Tosatti wrote:
On Tue, May 03, 2011 at 04:21:23PM +0300, Gleb Natapov wrote:
On Tue, May 03, 2011 at 10:13:17AM -0300, Marcelo Tosatti wrote:
Hi Gleb,
Thats a neat idea.
On Thu, Apr 28, 2011 at 12:52:03PM +0300, Gleb Natapov wrote:
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). Lets treat
guest mode as quiescent state, just like we do with user-mode execution.
Signed-off-by: Gleb Natapov g...@redhat.com
---
include/linux/kvm_host.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 0bc3d37..a347bce 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -593,6 +593,7 @@ static inline void kvm_guest_enter(void)
{
account_system_vtime(current);
current-flags |= PF_VCPU;
+ rcu_note_context_switch(smp_processor_id());
}
static inline void kvm_guest_exit(void)
--
1.7.2.3
Please have it in x86's vcpu_enter_guest, then its more explicit
(uncertain about the context of kvm_guest_enter call in other arches).
I checked all of them and kvm_guest_enter() is always called with local
irq disabled. Paul confirmed that rcu_note_context_switch() can be
called in such context.
OK then. Perhaps have an assert to verify interrupts are disabled?
Yes. Can add BUG_ON(preemptible()).
--
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 May 03rd
On 05/03/11 15:04, Jan Kiszka wrote: On 2011-05-03 12:21, Juan Quintela wrote: Please send in any agenda items you are interested in covering. Provided there will be more topics: - import kvm headers into qemu, drop #ifdef maze Otherwise, we can also discuss this based on the patch I'm preparing ATM. Since this it the only topic for the call, I suggest we cancel and add it to next week's agenda. Cheers, 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
[RFC][PATCH] Import Linux headers for KVM and vhost
This helps reducing our build-time checks for feature support in the
available Linux kernel headers. And it helps users that do not have
sufficiently recent headers installed on their build machine.
Header upstate is triggered via 'make update-linux-headers', optionally
specifying a kernel directory as source via 'LINUX='.
---
I'm sure this is not yet perfect from technical POV (e.g. the patch to
Makefile.target looks like a hack to me, better ideas welcome),
therefore RFC and no SOB. But it should demonstrate the plan. The
workflow for adding a new KVM feature support would be first a 'make
update-linux-header LINUX=/my/local/linux' + git commit, and then the
commit of the kvm, vhost, whatever changes.
A patch to actually add the result of the header update would be posted
separately. Same for the now possible massive cleanups of kvm sources.
Makefile| 17 +++
Makefile.target |2 +-
configure | 127 ---
3 files changed, 36 insertions(+), 110 deletions(-)
diff --git a/Makefile b/Makefile
index 67c0268..6ca065b 100644
--- a/Makefile
+++ b/Makefile
@@ -341,3 +341,20 @@ tarbin:
# Include automatically generated dependency files
-include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d)
+
+update-linux-headers:
+ for arch in x86 powerpc s390; do \
+ $(MAKE) -C $(LINUX) INSTALL_HDR_PATH=`pwd`/.tmp-hdrs
SRCARCH=$$arch headers_install; \
+ rm -rf $(SRC_PATH)/include/asm-$$arch/*; \
+ for header in kvm.h kvm_para.h; do \
+ cp .tmp-hdrs/include/asm/$$header
$(SRC_PATH)/include/asm-$$arch; \
+ done; \
+ if test $$arch == x86; then \
+ cp .tmp-hdrs/include/asm/hyperv.h
$(SRC_PATH)/include/asm-x86; \
+ fi \
+ done
+ rm -rf $(SRC_PATH)/include/linux/*
+ for header in kvm.h kvm_para.h vhost.h virtio_config.h virtio_ring.h;
do \
+ cp .tmp-hdrs/include/linux/$$header $(SRC_PATH)/include/linux; \
+ done
+ rm -rf .tmp-hdrs
diff --git a/Makefile.target b/Makefile.target
index 89280c6..b0fe021 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -14,7 +14,7 @@ endif
TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH)
$(call set-vpath, $(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw)
-QEMU_CFLAGS+= -I.. -I$(TARGET_PATH) -DNEED_CPU_H
+QEMU_CFLAGS+= -I.. -I../include -I$(TARGET_PATH) -DNEED_CPU_H
include $(SRC_PATH)/Makefile.objs
diff --git a/configure b/configure
index 3239fbb..792e4c2 100755
--- a/configure
+++ b/configure
@@ -113,8 +113,7 @@ curl=
curses=
docs=
fdt=
-kvm=
-kvm_para=
+kvm=yes
nptl=
sdl=
vnc=yes
@@ -129,7 +128,7 @@ vnc_thread=no
xen=
linux_aio=
attr=
-vhost_net=
+vhost_net=yes
xfs=
gprof=no
@@ -1695,109 +1694,6 @@ EOF
fi
##
-# kvm probe
-if test $kvm != no ; then
-cat $TMPC EOF
-#include linux/kvm.h
-#if !defined(KVM_API_VERSION) || KVM_API_VERSION 12 || KVM_API_VERSION 12
-#error Invalid KVM version
-#endif
-EOF
-must_have_caps=KVM_CAP_USER_MEMORY \
-KVM_CAP_DESTROY_MEMORY_REGION_WORKS \
-KVM_CAP_COALESCED_MMIO \
-KVM_CAP_SYNC_MMU \
-
-if test \( $cpu = i386 -o $cpu = x86_64 \) ; then
- must_have_caps=$caps \
- KVM_CAP_SET_TSS_ADDR \
- KVM_CAP_EXT_CPUID \
- KVM_CAP_CLOCKSOURCE \
- KVM_CAP_NOP_IO_DELAY \
- KVM_CAP_PV_MMU \
- KVM_CAP_MP_STATE \
- KVM_CAP_USER_NMI \
-
-fi
-for c in $must_have_caps ; do
- cat $TMPC EOF
-#if !defined($c)
-#error Missing KVM capability $c
-#endif
-EOF
-done
-cat $TMPC EOF
-int main(void) { return 0; }
-EOF
- if test $kerneldir != ; then
- kvm_cflags=-I$kerneldir/include
- if test \( $cpu = i386 -o $cpu = x86_64 \) \
- -a -d $kerneldir/arch/x86/include ; then
-kvm_cflags=$kvm_cflags -I$kerneldir/arch/x86/include
- elif test $cpu = ppc -a -d $kerneldir/arch/powerpc/include ; then
- kvm_cflags=$kvm_cflags -I$kerneldir/arch/powerpc/include
- elif test $cpu = s390x -a -d $kerneldir/arch/s390/include ; then
- kvm_cflags=$kvm_cflags -I$kerneldir/arch/s390/include
-elif test -d $kerneldir/arch/$cpu/include ; then
-kvm_cflags=$kvm_cflags -I$kerneldir/arch/$cpu/include
- fi
- else
-kvm_cflags=`$pkg_config --cflags kvm-kmod 2/dev/null`
- fi
- if compile_prog $kvm_cflags ; then
-kvm=yes
-cat $TMPC EOF
-#include linux/kvm_para.h
-int main(void) { return 0; }
-EOF
-if compile_prog $kvm_cflags ; then
- kvm_para=yes
-fi
- else
-if test $kvm = yes ; then
- if has awk has grep; then
-kvmerr=`LANG=C $cc $QEMU_CFLAGS -o $TMPE $kvm_cflags $TMPC 21
Re: [Qemu-devel] KVM call agenda for May 03rd
On 2011-05-03 15:07, Anthony Liguori wrote: On 05/03/2011 08:04 AM, Jan Kiszka wrote: On 2011-05-03 12:21, Juan Quintela wrote: Please send in any agenda items you are interested in covering. Provided there will be more topics: - import kvm headers into qemu, drop #ifdef maze This has come up a few times in the past. The opposition tends to be that it would make feature development harder because you couldn't easily point QEMU at a different set of kernel headers. There should be no need to worry, even if for those bits that will continue to change more frequently. I've included a hopefully easy to use update mechanism. These days, so few things change in the KVM interface though that maybe it's not the end of the world. PowerPC and future KVM arch will go through the same changes that x86 should be through now. So I would prefer to avoid the mistakes we made for the latter. 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 6/6] KVM: PPC: Add kvm headers to headers_install
On 2011-05-03 14:37, Alexander Graf wrote: When running make headers_install, we don't install kvm headers on PPC. This confuses Qemu, as it really wants to include kernel headers to know the ioctl structs. So let's add the arch/powerpc/include/asm headers that are important for KVM to the headers_install list. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/include/asm/Kbuild |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index d51df17..568b000 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -34,3 +34,5 @@ header-y += termios.h header-y += types.h header-y += ucontext.h header-y += unistd.h +header-y += kvm.h +header-y += kvm_para.h Weird, just worked for me with current kvm master without your patch. 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: nmi is broken?
On 2011-05-03 15:31, Avi Kivity wrote: On 05/03/2011 01:37 PM, Jan Kiszka wrote: Yes. Unfortunately that is very vendor and model specific. The architectural PMU is supported, but that is only available on Intel. Is it supposed to have any practical value already? I did not yet find a magic -cpu switch to let Linux detect anything, not to speak of perf or watchdog support. On the guest side it is supported for the watchdog (arch/x86/kernel/cpu/perfctr-watchdog.c, look for X86_FEATURE_ARCH_PERFMON). It's also mentioned in perf_event_intel.c, but I don't know if it will work without the other PMU features being present. I've tested with some SUSE 2.6.38 guest kernel, and it complained like this: (-cpu kvm64) Performance Events: unsupported Netburst CPU model 6 no PMU driver, software events only. NMI watchdog disabled (cpu0): hardware events not enabled or (-cpu host) Performance Events: unsupported p6 CPU model 37 no PMU driver, software events only. NMI watchdog disabled (cpu0): hardware events not enabled 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 6/6] KVM: PPC: Add kvm headers to headers_install
On 03.05.2011, at 16:20, Jan Kiszka wrote: On 2011-05-03 14:37, Alexander Graf wrote: When running make headers_install, we don't install kvm headers on PPC. This confuses Qemu, as it really wants to include kernel headers to know the ioctl structs. So let's add the arch/powerpc/include/asm headers that are important for KVM to the headers_install list. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/include/asm/Kbuild |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index d51df17..568b000 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -34,3 +34,5 @@ header-y += termios.h header-y += types.h header-y += ucontext.h header-y += unistd.h +header-y += kvm.h +header-y += kvm_para.h Weird, just worked for me with current kvm master without your patch. Oh? You did do make headers_install and it did push the correct headers to usr? Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nmi is broken?
On 05/03/2011 05:29 PM, Jan Kiszka wrote: On 2011-05-03 15:31, Avi Kivity wrote: On 05/03/2011 01:37 PM, Jan Kiszka wrote: Yes. Unfortunately that is very vendor and model specific. The architectural PMU is supported, but that is only available on Intel. Is it supposed to have any practical value already? I did not yet find a magic -cpu switch to let Linux detect anything, not to speak of perf or watchdog support. On the guest side it is supported for the watchdog (arch/x86/kernel/cpu/perfctr-watchdog.c, look for X86_FEATURE_ARCH_PERFMON). It's also mentioned in perf_event_intel.c, but I don't know if it will work without the other PMU features being present. I've tested with some SUSE 2.6.38 guest kernel, and it complained like this: (-cpu kvm64) Performance Events: unsupported Netburst CPU model 6 no PMU driver, software events only. NMI watchdog disabled (cpu0): hardware events not enabled Sorry, I meant to write, but forgot, that on the host side it is completely unsupported. It shouldn't be too hard to use perf_events to emulate the architectural PMU. Once we do that we can expose the architectural pmu bit and the guest will use it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] KVM: PPC: Add kvm headers to headers_install
On 2011-05-03 16:36, Alexander Graf wrote: On 03.05.2011, at 16:20, Jan Kiszka wrote: On 2011-05-03 14:37, Alexander Graf wrote: When running make headers_install, we don't install kvm headers on PPC. This confuses Qemu, as it really wants to include kernel headers to know the ioctl structs. So let's add the arch/powerpc/include/asm headers that are important for KVM to the headers_install list. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/include/asm/Kbuild |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index d51df17..568b000 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -34,3 +34,5 @@ header-y += termios.h header-y += types.h header-y += ucontext.h header-y += unistd.h +header-y += kvm.h +header-y += kvm_para.h Weird, just worked for me with current kvm master without your patch. Oh? You did do make headers_install and it did push the correct headers to usr? I strongly suspect. It's all documented in my header patch. 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: nmi is broken?
On 2011-05-03 16:37, Avi Kivity wrote: On 05/03/2011 05:29 PM, Jan Kiszka wrote: On 2011-05-03 15:31, Avi Kivity wrote: On 05/03/2011 01:37 PM, Jan Kiszka wrote: Yes. Unfortunately that is very vendor and model specific. The architectural PMU is supported, but that is only available on Intel. Is it supposed to have any practical value already? I did not yet find a magic -cpu switch to let Linux detect anything, not to speak of perf or watchdog support. On the guest side it is supported for the watchdog (arch/x86/kernel/cpu/perfctr-watchdog.c, look for X86_FEATURE_ARCH_PERFMON). It's also mentioned in perf_event_intel.c, but I don't know if it will work without the other PMU features being present. I've tested with some SUSE 2.6.38 guest kernel, and it complained like this: (-cpu kvm64) Performance Events: unsupported Netburst CPU model 6 no PMU driver, software events only. NMI watchdog disabled (cpu0): hardware events not enabled Sorry, I meant to write, but forgot, that on the host side it is completely unsupported. It shouldn't be too hard to use perf_events to emulate the architectural PMU. Once we do that we can expose the architectural pmu bit and the guest will use it. Oh, and I already thought I would have missed some thrilling KVM patches... 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 6/6] KVM: PPC: Add kvm headers to headers_install
On 03.05.2011, at 16:44, Jan Kiszka wrote: On 2011-05-03 16:36, Alexander Graf wrote: On 03.05.2011, at 16:20, Jan Kiszka wrote: On 2011-05-03 14:37, Alexander Graf wrote: When running make headers_install, we don't install kvm headers on PPC. This confuses Qemu, as it really wants to include kernel headers to know the ioctl structs. So let's add the arch/powerpc/include/asm headers that are important for KVM to the headers_install list. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/include/asm/Kbuild |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index d51df17..568b000 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -34,3 +34,5 @@ header-y += termios.h header-y += types.h header-y += ucontext.h header-y += unistd.h +header-y += kvm.h +header-y += kvm_para.h Weird, just worked for me with current kvm master without your patch. Oh? You did do make headers_install and it did push the correct headers to usr? I strongly suspect. It's all documented in my header patch. Your header patch manually copies the respective files, so you're not using that code path there? Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] KVM: PPC: Add kvm headers to headers_install
On 2011-05-03 17:04, Alexander Graf wrote: On 03.05.2011, at 16:44, Jan Kiszka wrote: On 2011-05-03 16:36, Alexander Graf wrote: On 03.05.2011, at 16:20, Jan Kiszka wrote: On 2011-05-03 14:37, Alexander Graf wrote: When running make headers_install, we don't install kvm headers on PPC. This confuses Qemu, as it really wants to include kernel headers to know the ioctl structs. So let's add the arch/powerpc/include/asm headers that are important for KVM to the headers_install list. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/include/asm/Kbuild |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index d51df17..568b000 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -34,3 +34,5 @@ header-y += termios.h header-y += types.h header-y += ucontext.h header-y += unistd.h +header-y += kvm.h +header-y += kvm_para.h Weird, just worked for me with current kvm master without your patch. Oh? You did do make headers_install and it did push the correct headers to usr? I strongly suspect. It's all documented in my header patch. Your header patch manually copies the respective files, so you're not using that code path there? I'm copying from the output dir auf headers_install (INSTALL_HDR_PATH). What step does this patch target at? 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: [Qemu-devel] [RFC][PATCH] Import Linux headers for KVM and vhost
On Tue, May 03, 2011 at 04:05:37PM +0200, Jan Kiszka wrote: This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine. Header upstate is triggered via 'make update-linux-headers', optionally specifying a kernel directory as source via 'LINUX='. Why not make it a shell scripts? It's not like it's part of the build system. I also think the source tree argument should be mandatory instead of grabbing random headers. -- 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 6/6] KVM: PPC: Add kvm headers to headers_install
On 03.05.2011, at 17:10, Jan Kiszka wrote: On 2011-05-03 17:04, Alexander Graf wrote: On 03.05.2011, at 16:44, Jan Kiszka wrote: On 2011-05-03 16:36, Alexander Graf wrote: On 03.05.2011, at 16:20, Jan Kiszka wrote: On 2011-05-03 14:37, Alexander Graf wrote: When running make headers_install, we don't install kvm headers on PPC. This confuses Qemu, as it really wants to include kernel headers to know the ioctl structs. So let's add the arch/powerpc/include/asm headers that are important for KVM to the headers_install list. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/include/asm/Kbuild |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index d51df17..568b000 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -34,3 +34,5 @@ header-y += termios.h header-y += types.h header-y += ucontext.h header-y += unistd.h +header-y += kvm.h +header-y += kvm_para.h Weird, just worked for me with current kvm master without your patch. Oh? You did do make headers_install and it did push the correct headers to usr? I strongly suspect. It's all documented in my header patch. Your header patch manually copies the respective files, so you're not using that code path there? I'm copying from the output dir auf headers_install (INSTALL_HDR_PATH). What step does this patch target at? Ah, there it is. I find makefiles very hard to read :). No idea why it worked for you. I can certainly run make headers_install on a ppc machine later today and see if it magically started working on current master. :) Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC][PATCH] Import Linux headers for KVM and vhost
On 2011-05-03 17:12, Christoph Hellwig wrote: On Tue, May 03, 2011 at 04:05:37PM +0200, Jan Kiszka wrote: This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine. Header upstate is triggered via 'make update-linux-headers', optionally specifying a kernel directory as source via 'LINUX='. Why not make it a shell scripts? It's not like it's part of the build system. I also think the source tree argument should be mandatory instead of grabbing random headers. Yes, makes sense. I just adopted the kvm-kmod style here which I'm used to. 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 1/2] kvm tools: Fix virt_queue__set_used_elem
Increase idx only after updating the used element.
Not doing so may mark a buffer as used without having
it's head and length updated.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/virtio.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/virtio.c b/tools/kvm/virtio.c
index 6249521..b2d2407 100644
--- a/tools/kvm/virtio.c
+++ b/tools/kvm/virtio.c
@@ -7,9 +7,10 @@
struct vring_used_elem *virt_queue__set_used_elem(struct virt_queue *queue,
uint32_t head, uint32_t len)
{
struct vring_used_elem *used_elem;
- used_elem = queue-vring.used-ring[queue-vring.used-idx++ %
queue-vring.num];
+ used_elem = queue-vring.used-ring[queue-vring.used-idx %
queue-vring.num];
used_elem-id = head;
used_elem-len = len;
+ queue-vring.used-idx++;
return used_elem;
}
--
1.7.5.rc3
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] kvm tools: Protect from dup definitions in kernel header
The local kernel.h may redefine macros already defined otherwise, wrap it with #ifdef. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- tools/kvm/include/linux/kernel.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/tools/kvm/include/linux/kernel.h b/tools/kvm/include/linux/kernel.h index 8d83037..fccb624 100644 --- a/tools/kvm/include/linux/kernel.h +++ b/tools/kvm/include/linux/kernel.h @@ -1,10 +1,17 @@ #ifndef KVM__LINUX_KERNEL_H_ #define KVM__LINUX_KERNEL_H_ +#ifndef DIV_ROUND_UP #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) +#endif +#ifndef ALIGN #define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1) +#endif + +#ifndef __ALIGN_MASK #define __ALIGN_MASK(x,mask) (((x)+(mask))~(mask)) +#endif #ifndef offsetof #define offsetof(TYPE, MEMBER) ((size_t) ((TYPE *)0)-MEMBER) -- 1.7.5.rc3 -- 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] Import Linux headers for KVM and vhost
On Tuesday 03 May 2011, Jan Kiszka wrote: This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine. Header upstate is triggered via 'make update-linux-headers', optionally specifying a kernel directory as source via 'LINUX='. --- I'm sure this is not yet perfect from technical POV (e.g. the patch to Makefile.target looks like a hack to me, better ideas welcome), therefore RFC and no SOB. But it should demonstrate the plan. The workflow for adding a new KVM feature support would be first a 'make update-linux-header LINUX=/my/local/linux' + git commit, and then the commit of the kvm, vhost, whatever changes. Makefile| 17 +++ Makefile.target |2 +- configure | 127 --- 3 files changed, 36 insertions(+), 110 deletions(-) Very nice! The old way to poke into the kernel internals was really annoying and confusing. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] KVM: make guest mode entry to be rcu quiescent state
On Tue, May 03, 2011 at 04:39:01PM +0300, Gleb Natapov wrote:
On Thu, Apr 28, 2011 at 12:52:03PM +0300, Gleb Natapov wrote:
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). Lets
treat
guest mode as quiescent state, just like we do with user-mode
execution.
Signed-off-by: Gleb Natapov g...@redhat.com
---
include/linux/kvm_host.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 0bc3d37..a347bce 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -593,6 +593,7 @@ static inline void kvm_guest_enter(void)
{
account_system_vtime(current);
current-flags |= PF_VCPU;
+ rcu_note_context_switch(smp_processor_id());
}
static inline void kvm_guest_exit(void)
--
1.7.2.3
Please have it in x86's vcpu_enter_guest, then its more explicit
(uncertain about the context of kvm_guest_enter call in other arches).
I checked all of them and kvm_guest_enter() is always called with local
irq disabled. Paul confirmed that rcu_note_context_switch() can be
called in such context.
OK then. Perhaps have an assert to verify interrupts are disabled?
Yes. Can add BUG_ON(preemptible()).
Also please add a comment to explain whats going on. The commit message
above seems appropriate.
--
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 6/6] KVM: PPC: Add kvm headers to headers_install
On Tue, 3 May 2011 17:14:48 +0200 Alexander Graf ag...@suse.de wrote: Ah, there it is. I find makefiles very hard to read :). No idea why it worked for you. I can certainly run make headers_install on a ppc machine later today and see if it magically started working on current master. :) I've beet getting ppc asm/kvm.h using headers_install for a while now. Look at the top of include/asm-generic/Kbuild.asm -Scott -- 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] Import Linux headers for KVM and vhost
On 05/03/2011 07:48 PM, Jan Kiszka wrote: This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine. Header upstate is triggered via scripts/update-linux-headers.sh LINUX_PATH from the top-level QEMU source directory. Consequently, the patch removes and build-time checks for kvm and vhost in configure, and also the --kerneldir switch. Kernel headers are supposed to be provided by QEMU only. Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Some are explicitly GPLv2 - at least for QEMU that's fine in any case. Others are BSD which shall to be considered a compatible variant according to Rusty. Reluctant ack. (though for commit log cleanliness, the scripts and the headers should be in separate commits) -- 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: nmi is broken?
Avi Kivity a...@redhat.com writes: The issue with live migration is that we can't change the running configuration while the system is running, like adding the IMCR or changing the wiring. The hardware will be programmed for the old configuration and will likely fail with the new one. For example, the current wiring has the PIT output wired to PIC IRQ0 and IOAPIC INTI0; we need to change it to IOAPIC INTI2 instead. btw, I believe that the configuration currently implemented is legal (it's similar to config 7 in table 5-2 of the mpspec); the only problem is that it can't support the NMI watchdog through the I/O APIC trick, yet we allow it through a hack. I'm confused a bit. config 7 in table 5-2 says PIT output wired to IOAPIC INTIN2. So, we don't need to change it? We're like config 7 in that the 8259A output isn't wired to the IOAPIC. However we're unlike config 7 in that the PIT output is wired to IOAPIC INTIN0. I think we can keep it that way. Something we can do is connect the 8259A output to the I/O APIC INTIN2; it should be masked so live migration will continue to work. We just have to make sure that the guest is able to find that it is connected there. 8259A INTR to IOAPIC INTIN2 sounds strange. Isn't it IOAPIC INTIN0? Usually yes, but we already have the PIT wired to INTIN0. I saw that the kernel consults the mptable to see which pin to use, so with the right BIOS magic we can get things to work. Um..., I'm confused more. If so, MADT doesn't say it. MADT says irq == 0 is pin == 2, this is one of reasons why linux is quite silent in check_timer(). And I can't see why it is working by pin == 2 for IOAPIC. If I can make time, I'll see what happens by pin == 2 and pin == 0 of IOAPIC in kvm. Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp -- 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] Import Linux headers for KVM and vhost
On 2011-05-03 18:55, Avi Kivity wrote: On 05/03/2011 07:48 PM, Jan Kiszka wrote: This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine. Header upstate is triggered via scripts/update-linux-headers.sh LINUX_PATH from the top-level QEMU source directory. Consequently, the patch removes and build-time checks for kvm and vhost in configure, and also the --kerneldir switch. Kernel headers are supposed to be provided by QEMU only. Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Some are explicitly GPLv2 - at least for QEMU that's fine in any case. Others are BSD which shall to be considered a compatible variant according to Rusty. Reluctant ack. What downsides do you see? (though for commit log cleanliness, the scripts and the headers should be in separate commits) I'll split up in thread parts: script, headers, build system changes. 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: nmi is broken?
On 05/03/2011 07:57 PM, OGAWA Hirofumi wrote: Usually yes, but we already have the PIT wired to INTIN0. I saw that the kernel consults the mptable to see which pin to use, so with the right BIOS magic we can get things to work. Um..., I'm confused more. If so, MADT doesn't say it. MADT says irq == 0 is pin == 2, this is one of reasons why linux is quite silent in check_timer(). And I can't see why it is working by pin == 2 for IOAPIC. If I can make time, I'll see what happens by pin == 2 and pin == 0 of IOAPIC in kvm. You're right. The default routing is INTIN0, but qemu changes it to INTIN2 and tells kvm. So INTIN0 is free for the 8259A output. -- 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] Import Linux headers for KVM and vhost
On 05/03/2011 08:09 PM, Jan Kiszka wrote: Reluctant ack. What downsides do you see? The usual it shouldn't be this way. Every other package (including, I think, glibc) uses the sanitized system headers. Except for kvm-kmod, the system headers are always available. But if it's causing people pain, I don't want to insist. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On 3 May 2011 17:48, Jan Kiszka jan.kis...@siemens.com wrote: Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me... -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On Tue, May 03, 2011 at 08:13:04PM +0300, Avi Kivity wrote: On 05/03/2011 08:09 PM, Jan Kiszka wrote: Reluctant ack. What downsides do you see? The usual it shouldn't be this way. Every other package (including, I think, glibc) uses the sanitized system headers. Except for kvm-kmod, the system headers are always available. I agree, it doesn't feel quite right to bring in the headers. I don't have any alternative suggestions (besides better HOWTOs/Documentation) though. Cheers -- 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 3/8] Add userspace buffers support in skb
On Mon, 2011-05-02 at 13:53 +0300, Michael S. Tsirkin wrote:
On Wed, Apr 20, 2011 at 12:47:57PM -0700, Shirley Ma wrote:
This patch adds userspace buffers support in skb. A new struct
skb_ubuf_info is needed to maintain the userspace buffers argument
and index, a callback is used to notify userspace to release the
buffers once lower device has done DMA (Last reference to that skb
has gone).
Signed-off-by: Shirley Ma x...@us.ibm.com
---
include/linux/skbuff.h | 14 ++
net/core/skbuff.c | 15 ++-
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index d0ae90a..47a187b 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -189,6 +189,16 @@ enum {
SKBTX_DRV_NEEDS_SK_REF = 1 3,
};
+/* The callback notifies userspace to release buffers when skb DMA
is done in
+ * lower device, the desc is used to track userspace buffer index.
+ */
+struct skb_ubuf_info {
+ /* support buffers allocation from userspace */
+ void(*callback)(struct sk_buff *);
+ void*arg;
+ size_t desc;
+};
+
/* This data is invariant across clones and lives at
* the end of the header data, ie. at skb-end.
*/
@@ -211,6 +221,10 @@ struct skb_shared_info {
/* Intermediate layers must ensure that destructor_arg
* remains valid until skb destructor */
void * destructor_arg;
+
+ /* DMA mapping from/to userspace buffers */
+ struct skb_ubuf_info ubuf;
+
/* must be last field, see pskb_expand_head() */
skb_frag_t frags[MAX_SKB_FRAGS];
};
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7ebeed0..822c07d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -210,6 +210,8 @@ struct sk_buff *__alloc_skb(unsigned int size,
gfp_t gfp_mask,
shinfo = skb_shinfo(skb);
memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
atomic_set(shinfo-dataref, 1);
+ shinfo-ubuf.callback = NULL;
+ shinfo-ubuf.arg = NULL;
kmemcheck_annotate_variable(shinfo-destructor_arg);
if (fclone) {
@@ -327,7 +329,15 @@ static void skb_release_data(struct sk_buff
*skb)
for (i = 0; i skb_shinfo(skb)-nr_frags; i
++)
put_page(skb_shinfo(skb)-frags[i].page);
}
-
+ /*
+ * if skb buf is from userspace, we need to notify the
caller
+ * the lower device DMA has done;
+ */
+ if (skb_shinfo(skb)-ubuf.callback) {
+ skb_shinfo(skb)-ubuf.callback(skb);
+ skb_shinfo(skb)-ubuf.callback = NULL;
+ skb_shinfo(skb)-ubuf.arg = NULL;
+ }
if (skb_has_frag_list(skb))
skb_drop_fraglist(skb);
We probably don't need to touch arg if callback is NULL?
Yes.
@@ -480,6 +490,9 @@ bool skb_recycle_check(struct sk_buff *skb, int
skb_size)
if (irqs_disabled())
return false;
+ if (shinfo-ubuf.callback)
+ return false;
+
if (skb_is_nonlinear(skb) || skb-fclone !=
SKB_FCLONE_UNAVAILABLE)
return false;
This is not the only API unsupported for these skbs, is it?
Probably need to check and fail there as well.
Yes, I am going through all these skbs to make sure covering all.
Thanks
Shirley
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On 2011-05-03 19:32, Edgar E. Iglesias wrote: On Tue, May 03, 2011 at 08:13:04PM +0300, Avi Kivity wrote: On 05/03/2011 08:09 PM, Jan Kiszka wrote: Reluctant ack. What downsides do you see? The usual it shouldn't be this way. Every other package (including, I think, glibc) uses the sanitized system headers. Except for kvm-kmod, the system headers are always available. I agree, it doesn't feel quite right to bring in the headers. I don't have any alternative suggestions (besides better HOWTOs/Documentation) though. Again, the downside of the current approach are: - outdated distro headers silently disable features during build time (happened to me with vhost e.g.) - build breakages against older kernels / headers are pre-programmed as hardly anyone tests all the possible combinations - tons of #ifdef in the code + configure checks to catch the possible combinations Also note that [1] recommends this approach as well. I'm not aware of good examples, but I would be fairly surprised if we were the first to do this. Jan [1] http://kernelnewbies.org/KernelHeaders -- 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: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On 2011-05-03 19:30, Peter Maydell wrote: On 3 May 2011 17:48, Jan Kiszka jan.kis...@siemens.com wrote: Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me... I will discuss this internally again (with those people running the result through FOSSology sooner or later anyway). What about auto-importing the Linux top-level license file as well and putting it under include/? That would replicate what you find in Linux today and should at least maintain the level of pain, not increase it. 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 V3 2/8] Add a new zerocopy device flag
On Mon, 2011-05-02 at 22:53 +0300, Michael S. Tsirkin wrote: On Mon, May 02, 2011 at 11:47:08AM -0700, Shirley Ma wrote: On Mon, 2011-05-02 at 13:42 +0300, Michael S. Tsirkin wrote: This comment should specify what exactly is the promise the device makes by setting this flag. Specifically, the condition is that no skb fragments are used after the uinfo callback has been called. The way it's implemented, it probably means the device should not use any of skb_clone, expand head etc. Agree. Or maybe force a copy when device uses skb_clone, expand head ...? Thanks Shirley Copy from userspace upfront without locking is probably cheaper? Better to prevent this kind of skbs to be used in skb_clone, expand head for now. Thanks Shirley -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On 05/03/2011 12:30 PM, Peter Maydell wrote: On 3 May 2011 17:48, Jan Kiszkajan.kis...@siemens.com wrote: Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me... Which are the headers in question? Regards, Anthony Liguori -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nmi is broken?
Avi Kivity a...@redhat.com writes: On 05/03/2011 07:57 PM, OGAWA Hirofumi wrote: Usually yes, but we already have the PIT wired to INTIN0. I saw that the kernel consults the mptable to see which pin to use, so with the right BIOS magic we can get things to work. Um..., I'm confused more. If so, MADT doesn't say it. MADT says irq == 0 is pin == 2, this is one of reasons why linux is quite silent in check_timer(). And I can't see why it is working by pin == 2 for IOAPIC. If I can make time, I'll see what happens by pin == 2 and pin == 0 of IOAPIC in kvm. You're right. The default routing is INTIN0, but qemu changes it to INTIN2 and tells kvm. So INTIN0 is free for the 8259A output. I see. Did it mean qemu changes the wiring, so kvm can't work for live migration with it? Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On 2011-05-03 19:45, Anthony Liguori wrote: On 05/03/2011 12:30 PM, Peter Maydell wrote: On 3 May 2011 17:48, Jan Kiszkajan.kis...@siemens.com wrote: Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me... Which are the headers in question? include/asm-powerpc:explicit GPLv2 include/asm-s390: explicit GPLv2 include/asm/x86:no license mentioned include/linux/kvm*: no license mentioned include/linux/vhost:no license mentioned include/linux/virtio*: BSB The last group already popped up here during a license clearing of the kernel. I contacted Rusty on them and got the answer Standard 3 clause. The 4 clause is incompatible with the GPL. That was OK for our purposes, but I nevertheless asked Rusty to push a clarifying sentence to the kernel - unfortunately this did not happen so far. 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: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On Tue, 3 May 2011 19:32:00 +0200 Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Tue, May 03, 2011 at 08:13:04PM +0300, Avi Kivity wrote: On 05/03/2011 08:09 PM, Jan Kiszka wrote: Reluctant ack. What downsides do you see? The usual it shouldn't be this way. Every other package (including, I think, glibc) uses the sanitized system headers. Except for kvm-kmod, the system headers are always available. They're usually available, but often not recent. This turns qemu's kvm bits into an error-prone ifdef soup, and still requires the user to extract and point to their own set of sanitized kernel headers if they want the newer features (even if they don't have any other need to build a kernel). By including the headers in qemu, we can ensure that the headers are in sync with qemu's expectations. As for glibc, that's less likely to be built by an end-user, and more likely to be built by whoever was responsible for generating the system's sanitized headers. Even so, it probably relies on a bunch of autoconf gunk to deal with various versions of the headers. And glibc doesn't have the benefit of dynamic capability testing of the APIs -- it may be relying on the headers it builds against not being newer than the kernel it runs on. I agree, it doesn't feel quite right to bring in the headers. I don't have any alternative suggestions (besides better HOWTOs/Documentation) though. If you try to use the non-sanitized kernel headers, you'll get this warning from linux/types.h: #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders; At that URL, you'll find this: If you are distributing a user space program that depends on a specific version of some kernel headers, e.g. because your program runs only on patched or very recent kernels, you cannot rely on the headers in /usr/include. You also cannot use the header files from /usr/src/linux/include or /lib/modules/*/build/include/ because they have not been prepared for inclusion in user space. The kernel should warn you about this if you try it and point you to this Wiki page. The correct way to address this problem is to isolate the specific interfaces that you need, e.g. a single header file that is patched in a new kernel providing the ioctl numbers for a character device used by your program. In your own program, add a copy of that source file, with a notice that it should be kept in sync with new kernel versions. -Scott -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On 05/03/2011 12:55 PM, Jan Kiszka wrote: On 2011-05-03 19:45, Anthony Liguori wrote: On 05/03/2011 12:30 PM, Peter Maydell wrote: On 3 May 2011 17:48, Jan Kiszkajan.kis...@siemens.com wrote: Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me... Which are the headers in question? include/asm-powerpc:explicit GPLv2 include/asm-s390: explicit GPLv2 include/asm/x86:no license mentioned include/linux/kvm*: no license mentioned include/linux/vhost:no license mentioned Michael/Avi, can ya'll add copyrights/licenses as appropriate? include/linux/virtio*: BSB The last group already popped up here during a license clearing of the kernel. I contacted Rusty on them and got the answer Standard 3 clause. The 4 clause is incompatible with the GPL. That was OK for our purposes, but I nevertheless asked Rusty to push a clarifying sentence to the kernel - unfortunately this did not happen so far. Rusty, do you want to put together a patch with the full license or should I? Regards, Anthony Liguori 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: [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts
On Thu, Apr 28, 2011 at 04:25:00PM +0200, Ulrich Obergfell wrote:
Loss of periodic timer interrupts caused by delayed callbacks and by
interrupt coalescing is compensated by gradually injecting additional
interrupts during subsequent timer intervals, starting at a rate of
one additional interrupt per interval. The injection of additional
interrupts is based on a backlog of unaccounted HPET clock periods
(new HPETTimer field 'ticks_not_accounted'). The backlog increases
due to delayed callbacks and coalesced interrupts, and it decreases
if an interrupt was injected successfully. If the backlog increases
while compensation is still in progress, the rate at which additional
interrupts are injected is increased too. A limit is imposed on the
backlog and on the rate.
Injecting additional timer interrupts to compensate lost interrupts
can alleviate long term time drift. However, on a short time scale,
this method can have the side effect of making virtual machine time
intermittently pass slower and faster than real time (depending on
the guest's time keeping algorithm). Compensation is disabled by
default and can be enabled for guests where this behaviour may be
acceptable.
Signed-off-by: Ulrich Obergfell uober...@redhat.com
---
hw/hpet.c | 63 +++-
1 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 35466ae..92d5f58 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -32,6 +32,7 @@
#include sysbus.h
#include mc146818rtc.h
#include sysemu.h
+#include assert.h
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -42,6 +43,9 @@
#define HPET_MSI_SUPPORT0
+#define MAX_TICKS_NOT_ACCOUNTED (uint64_t)5 /* 5 sec */
+#define MAX_IRQ_RATE(uint32_t)10
+
struct HPETState;
typedef struct HPETTimer { /* timers */
uint8_t tn; /*timer number*/
@@ -326,28 +330,63 @@ static const VMStateDescription vmstate_hpet = {
}
};
+static bool hpet_timer_has_tick_backlog(HPETTimer *t)
+{
+uint64_t backlog = t-ticks_not_accounted - (t-period + t-prev_period);
+return (backlog = t-period);
+}
+
/*
* timer expiration callback
*/
static void hpet_timer(void *opaque)
{
HPETTimer *t = opaque;
+HPETState *s = t-state;
uint64_t diff;
-
+int irq_delivered = 0;
+uint32_t irq_count = 0;
uint64_t period = t-period;
uint64_t cur_tick = hpet_get_ticks(t-state);
+if (s-driftfix !t-ticks_not_accounted) {
+t-ticks_not_accounted = t-prev_period = t-period;
+}
if (timer_is_periodic(t) period != 0) {
if (t-config HPET_TN_32BIT) {
while (hpet_time_after(cur_tick, t-cmp)) {
t-cmp = (uint32_t)(t-cmp + t-period);
+t-ticks_not_accounted += t-period;
+irq_count++;
}
} else {
while (hpet_time_after64(cur_tick, t-cmp)) {
t-cmp += period;
+t-ticks_not_accounted += period;
+irq_count++;
}
}
diff = hpet_calculate_diff(t, cur_tick);
+if (s-driftfix) {
+if (t-ticks_not_accounted MAX_TICKS_NOT_ACCOUNTED) {
+t-ticks_not_accounted = t-period + t-prev_period;
+}
+if (hpet_timer_has_tick_backlog(t)) {
+if (t-irq_rate == 1 || irq_count 1) {
+t-irq_rate++;
+t-irq_rate = MIN(t-irq_rate, MAX_IRQ_RATE);
+}
+if (t-divisor == 0) {
+assert(irq_count);
+}
+if (irq_count) {
+t-divisor = t-irq_rate;
+}
+diff /= t-divisor--;
+} else {
+t-irq_rate = 1;
+}
+}
qemu_mod_timer(t-qemu_timer,
qemu_get_clock_ns(vm_clock) +
(int64_t)ticks_to_ns(diff));
} else if (t-config HPET_TN_32BIT !timer_is_periodic(t)) {
@@ -358,7 +397,22 @@ static void hpet_timer(void *opaque)
t-wrap_flag = 0;
}
}
-update_irq(t, 1);
+if (s-driftfix timer_is_periodic(t) period != 0) {
+if (t-ticks_not_accounted = t-period + t-prev_period) {
+irq_delivered = update_irq(t, 1);
+if (irq_delivered) {
+t-ticks_not_accounted -= t-prev_period;
+t-prev_period = t-period;
+} else {
+if (irq_count) {
+t-irq_rate++;
+t-irq_rate = MIN(t-irq_rate, MAX_IRQ_RATE);
+}
+}
+}
+} else {
+update_irq(t, 1);
+}
}
Hi Ulrich,
Whats prev_period for, since in practice the period will not change
between interrupts (OS programs comparator once, or perhaps
Re: [PATCH] qemu-kvm: Do not advertise MSI caps on lacking KVM support
On Fri, Apr 29, 2011 at 01:24:49PM +0200, Jan Kiszka wrote: As suggested by Michael Tsirkin: Move the check for GSI routing from kvm_msi_message_add to the MSI/MSI-X initalization. If it fails (and KVM is in in-kernel irqchip mode), do not advertise MSI at all. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: Limit MSI vector walk to actual array size
On Fri, Apr 29, 2011 at 01:24:59PM +0200, Jan Kiszka wrote: We only need to walk as many vectors on updates as the device supports. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] qemu-kvm: pci-assign: Some more cleanups
On Fri, Apr 29, 2011 at 11:05:27AM +0200, Jan Kiszka wrote: This round addresses the review comments and also add another fix to ensure that non-virtualized config areas always hit the real device. Jan Kiszka (6): pci-assign: Clean up assigned_dev_pci_read/write_config pci-assign: Move merge_bits pci-assign: Fix dword read at PCI_COMMAND pci-assign: Properly handle more overlapping accesses pci-assign: Remove suspicious hunk from assigned_dev_pci_read_config pci-assign: Convert need_emulate_cmd into a bitmask Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On Tuesday 03 May 2011 19:57:18 Scott Wood wrote: I agree, it doesn't feel quite right to bring in the headers. I don't have any alternative suggestions (besides better HOWTOs/Documentation) though. If you try to use the non-sanitized kernel headers, you'll get this warning from linux/types.h: #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders; You're welcome ;-) I tried to make the recommended approach as clear as I could with the #warning and the wiki page. If there is anything still unclear about how it should be done, please make suggestions for improving the wiki text. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] rcu: export rcu_note_context_switch() function
On Mon, May 02, 2011 at 05:10:03PM +0300, Gleb Natapov wrote:
On Mon, May 02, 2011 at 06:36:08AM -0700, Paul E. McKenney wrote:
On Mon, May 02, 2011 at 01:56:12PM +0300, Gleb Natapov wrote:
On Sat, Apr 30, 2011 at 05:59:28AM -0700, Paul E. McKenney wrote:
On Fri, Apr 29, 2011 at 09:02:39PM +0300, Gleb Natapov wrote:
On Fri, Apr 29, 2011 at 01:39:04AM -0700, Paul E. McKenney wrote:
On Fri, Apr 29, 2011 at 01:36:18AM -0700, Paul E. McKenney wrote:
On Thu, Apr 28, 2011 at 12:52:02PM +0300, Gleb Natapov wrote:
Hmmm This is interesting. KVM being a module, we either
expand
TINY_RCU's size a bit by making rcu_note_context_switch() be a
real
function in rcutiny.c and adding an export, or we expand it by
adding
two exports.
I would like to solve this without making TINY_RCU larger, and
preferably
by making it smaller. Any ideas come to mind? (Other than making
KVM depend on CONFIG_SMP, which sounds too much like throwing out
the
baby with the bathwater.)
Nothing quite like hitting send to make an idea show up...
In a UP kernel, does it actually help anything to have KVM
tell RCU about executing in a guest? If not, could we have a
rcu_note_context_switch_kvm() that is a static inline empty
function in
TINY_RCU and maps to rcu_note_context_switch() for TREE_RCU?
That will work, but does making rcu_note_context_switch() out of line
actually increase kernel size? The function is called in two places
currently, so by making it out of line we make two calling site
smaller.
Will measure it next week.
One thing to keep in mind... Calling an out-of-line function from
KVM requires an export, each of which significantly increases TINY_RCU's
memory footprint.
Thanx, Paul
How significantly? As I wrote in other mail I compiled two TINY_RCU
kernel with and without the patch and I didn't see memory footprint
increase at all. May be I measure it incorrectly, but what I see is that
with out of line function + export text section becomes 64 byte bigger,
but
data section becomes 64 byte smaller:
textdata bss dec hex filename
4544134 590596 2023424 7158154 6d398a vmlinux inline
4544198 590532 2023424 7158154 6d398a vmlinux.ol out of line
Did you add the exports that would be needed to allow KVM to call
the functions in the inline case?
Yes, this is with and without patch applied. When patch is applied the
function is out of line and exported.
OK, here is what I am suggesting -- create a separate API for virtualization,
make it be an empty static inline function for TINY, and make it a wrapper
for TREE. This gets rid of the export in the TINY case, and takes advantage
of the single-CPU constraint in the TINY case. So this gains the benefit
of uninlining rcu_note_context_switch(), but avoids paying the cost of the
EXPORT_SYMBOL_GPL().
Then you call rcu_virt_note_context_switch() in place of
rcu_note_context_switch() from KVM.
Does this make sense?
Thanx, Paul
include/linux/rcutiny.h |8
include/linux/rcutree.h | 10 ++
kernel/rcutiny.c|1 -
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index 8e5f7cf..3cc60c0 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -96,6 +96,14 @@ static inline int rcu_needs_cpu(int cpu)
extern void rcu_note_context_switch(int cpu);
/*
+ * Take advantage of the fact that there is only one CPU, which
+ * allows us to ignore virtualization-based context switches.
+ */
+static inline void rcu_virt_note_context_switch(int cpu)
+{
+}
+
+/*
* Return the number of grace periods.
*/
static inline long rcu_batches_completed(void)
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 284dad1..e65d066 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -35,6 +35,16 @@ extern void rcu_note_context_switch(int cpu);
extern int rcu_needs_cpu(int cpu);
extern void rcu_cpu_stall_reset(void);
+/*
+ * Note a virtualization-based context switch. This is simply a
+ * wrapper around rcu_note_context_switch(), which allows TINY_RCU
+ * to save a few bytes.
+ */
+static inline void rcu_virt_note_context_switch(int cpu)
+{
+ rcu_note_context_switch(cpu);
+}
+
#ifdef CONFIG_TREE_PREEMPT_RCU
extern void exit_rcu(void);
diff --git a/kernel/rcutiny.c b/kernel/rcutiny.c
index 44d6479..8071010 100644
--- a/kernel/rcutiny.c
+++ b/kernel/rcutiny.c
@@ -83,7 +83,6 @@ void rcu_note_context_switch(int cpu)
rcu_sched_qs(cpu);
Re: [PATCH 1/2] kvm tools: Fix virt_queue__set_used_elem
* Sasha Levin levinsasha...@gmail.com wrote:
Increase idx only after updating the used element.
Not doing so may mark a buffer as used without having
it's head and length updated.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/virtio.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/virtio.c b/tools/kvm/virtio.c
index 6249521..b2d2407 100644
--- a/tools/kvm/virtio.c
+++ b/tools/kvm/virtio.c
@@ -7,9 +7,10 @@
struct vring_used_elem *virt_queue__set_used_elem(struct virt_queue *queue,
uint32_t head, uint32_t len)
{
struct vring_used_elem *used_elem;
- used_elem = queue-vring.used-ring[queue-vring.used-idx++ %
queue-vring.num];
+ used_elem = queue-vring.used-ring[queue-vring.used-idx %
queue-vring.num];
used_elem-id = head;
used_elem-len = len;
+ queue-vring.used-idx++;
return used_elem;
}
Note that both the compiler and the CPU can reorder this code arbitrarily, so
your patch does not address the problem.
As mentioned in earlier discussions, you need memory barriers (which also act
as compiler barriers) to express this dependency in the order of updates to
these data structures.
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] kvm tools: Protect from dup definitions in kernel header
* Sasha Levin levinsasha...@gmail.com wrote: The local kernel.h may redefine macros already defined otherwise, wrap it with #ifdef. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- tools/kvm/include/linux/kernel.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/tools/kvm/include/linux/kernel.h b/tools/kvm/include/linux/kernel.h index 8d83037..fccb624 100644 --- a/tools/kvm/include/linux/kernel.h +++ b/tools/kvm/include/linux/kernel.h @@ -1,10 +1,17 @@ #ifndef KVM__LINUX_KERNEL_H_ #define KVM__LINUX_KERNEL_H_ +#ifndef DIV_ROUND_UP #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) +#endif +#ifndef ALIGN #define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1) +#endif + +#ifndef __ALIGN_MASK #define __ALIGN_MASK(x,mask) (((x)+(mask))~(mask)) +#endif Hm, how can duplicate definitions happen? Only one place should define them - otherwise we might end up with incompatible definitions ... Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] kvm tools: Protect from dup definitions in kernel header
On Tue, 2011-05-03 at 21:49 +0200, Ingo Molnar wrote: * Sasha Levin levinsasha...@gmail.com wrote: The local kernel.h may redefine macros already defined otherwise, wrap it with #ifdef. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- tools/kvm/include/linux/kernel.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/tools/kvm/include/linux/kernel.h b/tools/kvm/include/linux/kernel.h index 8d83037..fccb624 100644 --- a/tools/kvm/include/linux/kernel.h +++ b/tools/kvm/include/linux/kernel.h @@ -1,10 +1,17 @@ #ifndef KVM__LINUX_KERNEL_H_ #define KVM__LINUX_KERNEL_H_ +#ifndef DIV_ROUND_UP #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) +#endif +#ifndef ALIGN #define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1) +#endif + +#ifndef __ALIGN_MASK #define __ALIGN_MASK(x,mask) (((x)+(mask))~(mask)) +#endif Hm, how can duplicate definitions happen? Only one place should define them - otherwise we might end up with incompatible definitions ... We has ALIGN defined in include/kvm/bios.h within our code. -- Sasha. -- 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 2/2] kvm tools: Protect from dup definitions in kernel header
* Sasha Levin levinsasha...@gmail.com wrote: On Tue, 2011-05-03 at 21:49 +0200, Ingo Molnar wrote: * Sasha Levin levinsasha...@gmail.com wrote: The local kernel.h may redefine macros already defined otherwise, wrap it with #ifdef. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- tools/kvm/include/linux/kernel.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/tools/kvm/include/linux/kernel.h b/tools/kvm/include/linux/kernel.h index 8d83037..fccb624 100644 --- a/tools/kvm/include/linux/kernel.h +++ b/tools/kvm/include/linux/kernel.h @@ -1,10 +1,17 @@ #ifndef KVM__LINUX_KERNEL_H_ #define KVM__LINUX_KERNEL_H_ +#ifndef DIV_ROUND_UP #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) +#endif +#ifndef ALIGN #define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1) +#endif + +#ifndef __ALIGN_MASK #define __ALIGN_MASK(x,mask) (((x)+(mask))~(mask)) +#endif Hm, how can duplicate definitions happen? Only one place should define them - otherwise we might end up with incompatible definitions ... We has ALIGN defined in include/kvm/bios.h within our code. Well, but then the right solution would be to not define it there but remove it, and use the one we get from the kernel headers? Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] kvm tools: Protect from dup definitions in kernel header
On 05/03/2011 11:59 PM, Ingo Molnar wrote: ... Hm, how can duplicate definitions happen? Only one place should define them - otherwise we might end up with incompatible definitions ... We has ALIGN defined in include/kvm/bios.h within our code. Well, but then the right solution would be to not define it there but remove it, and use the one we get from the kernel headers? Thanks, Ingo Yeah, the right way indeed to use kernel header. The former ALIGN was introduced by me I fear when kvm tools were out of linux tree, ie quite early. Sasha mind to simply drop the former ALIGN out? -- Thanks, Cyrill -- 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 2/8] Add a new zerocopy device flag
On Tue, 2011-05-03 at 10:42 -0700, Shirley Ma wrote: Better to prevent this kind of skbs to be used in skb_clone, expand head for now. I looked at the code, skb_clone shouldn't have any problem since ubuf callback is only called after the lower device DMA has done. I can modify the zerocopy len to 256 bytes so expand head should be OK as well. So we only need to prevent recycle skb. I also checked the device drivers, only a few device do RX buffers recycle. So there shouldn't be any problem. I will add more comments here to make sure when ZEROCOPY flag is set, the ubuf callback should only be called when last reference to this skb is gone. Thanks Shirley -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On 3 May 2011 17:48, Jan Kiszka jan.kis...@siemens.com wrote: +++ b/scripts/update-linux-headers.sh @@ -0,0 +1,47 @@ +#!/bin/sh No -e ? +rm -rf $output/include/linux/* Given that updating the kernel headers will blow away large subsets of include/ like this, maybe we should use a less generic name than include, so it's clear that it's just a set of automatically maintained and updated files, rather than a good place to put random QEMU header files? kernel-headers/ seems like an obvious choice. Is it worth having a README in the directory saying don't edit these, they are copies of the kernel headers, they can be updated with whatever, or is that unnecessary? -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] kvm tools: Protect from dup definitions in kernel header
On 05/04/2011 12:10 AM, Cyrill Gorcunov wrote: On 05/03/2011 11:59 PM, Ingo Molnar wrote: ... Hm, how can duplicate definitions happen? Only one place should define them - otherwise we might end up with incompatible definitions ... We has ALIGN defined in include/kvm/bios.h within our code. Well, but then the right solution would be to not define it there but remove it, and use the one we get from the kernel headers? Thanks, Ingo Yeah, the right way indeed to use kernel header. The former ALIGN was introduced by me I fear when kvm tools were out of linux tree, ie quite early. Sasha mind to simply drop the former ALIGN out? Sasha, could you please also drop this lines from bios.h #ifndef ALIGN #define ALIGN(x, a) \ (((x) + ((a) - 1)) ~((a) - 1)) #endif /* * note we use 16 bytes alignment which makes segment based * addressing easy to compute, dont change it otherwise you * may break local variables offsets in BIOS irq routines */ #define BIOS_NEXT_IRQ_ADDR(addr, size) \ ALIGN((addr + size + 1), 16) they are rudiments. -- Thanks, Cyrill -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 V2] kvm tools: Drop ALIGN from bios.h
Drops align from bios.h, fixes related code to use linux/kernel.h instead. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- tools/kvm/include/kvm/bios.h | 13 - tools/kvm/mptable.c |1 + 2 files changed, 1 insertions(+), 13 deletions(-) diff --git a/tools/kvm/include/kvm/bios.h b/tools/kvm/include/kvm/bios.h index 914720b..7586e2a 100644 --- a/tools/kvm/include/kvm/bios.h +++ b/tools/kvm/include/kvm/bios.h @@ -51,19 +51,6 @@ #define MB_BIOS_SS 0xfff7 #define MB_BIOS_SP 0x40 -#ifndef ALIGN -#define ALIGN(x, a)\ - (((x) + ((a) - 1)) ~((a) - 1)) -#endif - -/* - * note we use 16 bytes alignment which makes segment based - * addressing easy to compute, dont change it otherwise you - * may break local variables offsets in BIOS irq routines - */ -#define BIOS_NEXT_IRQ_ADDR(addr, size) \ - ALIGN((addr + size + 1), 16) - /* * When interfere with assembler code we need to be sure how * arguments are passed in real mode. diff --git a/tools/kvm/mptable.c b/tools/kvm/mptable.c index 5bbe7ea..b74c491 100644 --- a/tools/kvm/mptable.c +++ b/tools/kvm/mptable.c @@ -4,6 +4,7 @@ #include kvm/mptable.h #include kvm/util.h +#include linux/kernel.h #include string.h /* -- 1.7.5.rc3 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 V2] kvm tools: Fix virt_queue__set_used_elem
Increase idx only after updating the used element.
Not doing so may mark a buffer as used without having
it's head and length updated.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/virtio.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/virtio.c b/tools/kvm/virtio.c
index 6249521..266a1b6 100644
--- a/tools/kvm/virtio.c
+++ b/tools/kvm/virtio.c
@@ -1,15 +1,32 @@
#include linux/virtio_ring.h
#include stdint.h
#include sys/uio.h
+#include asm/system.h
#include kvm/kvm.h
#include kvm/virtio.h
struct vring_used_elem *virt_queue__set_used_elem(struct virt_queue *queue,
uint32_t head, uint32_t len)
{
struct vring_used_elem *used_elem;
- used_elem = queue-vring.used-ring[queue-vring.used-idx++ %
queue-vring.num];
+ used_elem = queue-vring.used-ring[queue-vring.used-idx %
queue-vring.num];
used_elem-id = head;
used_elem-len = len;
+
+ /*
+* Use wmb to assure that used elem was updated with head and len.
+* We need a wmb here since we can't advance idx unless we're ready
+* to pass the used element to the guest.
+*/
+ wmb();
+ queue-vring.used-idx++;
+
+ /*
+* Use wmb to assure used idx has been increased before we signal the
guest.
+* Without a wmb here the guest may ignore the queue since it won't see
+* an updated idx.
+*/
+ wmb();
+
return used_elem;
}
--
1.7.5.rc3
--
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 V2] kvm tools: Drop ALIGN from bios.h
On 05/04/2011 12:28 AM, Sasha Levin wrote: Drops align from bios.h, fixes related code to use linux/kernel.h instead. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- ... Looks good to me, thanks Sasha. (I suspect it still builds and run, right? :) -- Thanks, Cyrill -- 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 2/2 V2] kvm tools: Fix virt_queue__set_used_elem
* Sasha Levin levinsasha...@gmail.com wrote: Increase idx only after updating the used element. Not doing so may mark a buffer as used without having it's head and length updated. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- tools/kvm/virtio.c | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/tools/kvm/virtio.c b/tools/kvm/virtio.c index 6249521..266a1b6 100644 --- a/tools/kvm/virtio.c +++ b/tools/kvm/virtio.c @@ -1,15 +1,32 @@ #include linux/virtio_ring.h #include stdint.h #include sys/uio.h +#include asm/system.h If this system.h is included from the current kernel (and not from the system's) then: Acked-by: Ingo Molnar mi...@elte.hu Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
On Tue, May 03, 2011 at 12:59:06PM -0500, Anthony Liguori wrote: On 05/03/2011 12:55 PM, Jan Kiszka wrote: On 2011-05-03 19:45, Anthony Liguori wrote: On 05/03/2011 12:30 PM, Peter Maydell wrote: On 3 May 2011 17:48, Jan Kiszkajan.kis...@siemens.com wrote: Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me... Which are the headers in question? include/asm-powerpc: explicit GPLv2 include/asm-s390:explicit GPLv2 include/asm/x86: no license mentioned include/linux/kvm*: no license mentioned include/linux/vhost: no license mentioned Michael/Avi, can ya'll add copyrights/licenses as appropriate? All kernel is GPLv2 with userspace exceptions. The explicit GPLv2 licenses are likely uninitentional. So I don't really believe licenses are applicable in headers, we see how this creates confusion. Just place the kernel COPYING file into the include directory? include/linux/virtio*: BSB The last group already popped up here during a license clearing of the kernel. I contacted Rusty on them and got the answer Standard 3 clause. The 4 clause is incompatible with the GPL. That was OK for our purposes, but I nevertheless asked Rusty to push a clarifying sentence to the kernel - unfortunately this did not happen so far. Rusty, do you want to put together a patch with the full license or should I? Regards, Anthony Liguori 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: [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts
On Tue, 2011-05-03 at 16:03 -0300, Marcelo Tosatti wrote:
On Thu, Apr 28, 2011 at 04:25:00PM +0200, Ulrich Obergfell wrote:
Loss of periodic timer interrupts caused by delayed callbacks and by
interrupt coalescing is compensated by gradually injecting additional
interrupts during subsequent timer intervals, starting at a rate of
one additional interrupt per interval. The injection of additional
interrupts is based on a backlog of unaccounted HPET clock periods
(new HPETTimer field 'ticks_not_accounted'). The backlog increases
due to delayed callbacks and coalesced interrupts, and it decreases
if an interrupt was injected successfully. If the backlog increases
while compensation is still in progress, the rate at which additional
interrupts are injected is increased too. A limit is imposed on the
backlog and on the rate.
Injecting additional timer interrupts to compensate lost interrupts
can alleviate long term time drift. However, on a short time scale,
this method can have the side effect of making virtual machine time
intermittently pass slower and faster than real time (depending on
the guest's time keeping algorithm). Compensation is disabled by
default and can be enabled for guests where this behaviour may be
acceptable.
Signed-off-by: Ulrich Obergfell uober...@redhat.com
---
hw/hpet.c | 63
+++-
1 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 35466ae..92d5f58 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -32,6 +32,7 @@
#include sysbus.h
#include mc146818rtc.h
#include sysemu.h
+#include assert.h
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -42,6 +43,9 @@
#define HPET_MSI_SUPPORT0
+#define MAX_TICKS_NOT_ACCOUNTED (uint64_t)5 /* 5 sec */
+#define MAX_IRQ_RATE(uint32_t)10
+
struct HPETState;
typedef struct HPETTimer { /* timers */
uint8_t tn; /*timer number*/
@@ -326,28 +330,63 @@ static const VMStateDescription vmstate_hpet = {
}
};
+static bool hpet_timer_has_tick_backlog(HPETTimer *t)
+{
+uint64_t backlog = t-ticks_not_accounted - (t-period +
t-prev_period);
+return (backlog = t-period);
+}
+
/*
* timer expiration callback
*/
static void hpet_timer(void *opaque)
{
HPETTimer *t = opaque;
+HPETState *s = t-state;
uint64_t diff;
-
+int irq_delivered = 0;
+uint32_t irq_count = 0;
uint64_t period = t-period;
uint64_t cur_tick = hpet_get_ticks(t-state);
+if (s-driftfix !t-ticks_not_accounted) {
+t-ticks_not_accounted = t-prev_period = t-period;
+}
if (timer_is_periodic(t) period != 0) {
if (t-config HPET_TN_32BIT) {
while (hpet_time_after(cur_tick, t-cmp)) {
t-cmp = (uint32_t)(t-cmp + t-period);
+t-ticks_not_accounted += t-period;
+irq_count++;
}
} else {
while (hpet_time_after64(cur_tick, t-cmp)) {
t-cmp += period;
+t-ticks_not_accounted += period;
+irq_count++;
}
}
diff = hpet_calculate_diff(t, cur_tick);
+if (s-driftfix) {
+if (t-ticks_not_accounted MAX_TICKS_NOT_ACCOUNTED) {
+t-ticks_not_accounted = t-period + t-prev_period;
+}
+if (hpet_timer_has_tick_backlog(t)) {
+if (t-irq_rate == 1 || irq_count 1) {
+t-irq_rate++;
+t-irq_rate = MIN(t-irq_rate, MAX_IRQ_RATE);
+}
+if (t-divisor == 0) {
+assert(irq_count);
+}
+if (irq_count) {
+t-divisor = t-irq_rate;
+}
+diff /= t-divisor--;
+} else {
+t-irq_rate = 1;
+}
+}
qemu_mod_timer(t-qemu_timer,
qemu_get_clock_ns(vm_clock) +
(int64_t)ticks_to_ns(diff));
} else if (t-config HPET_TN_32BIT !timer_is_periodic(t)) {
@@ -358,7 +397,22 @@ static void hpet_timer(void *opaque)
t-wrap_flag = 0;
}
}
-update_irq(t, 1);
+if (s-driftfix timer_is_periodic(t) period != 0) {
+if (t-ticks_not_accounted = t-period + t-prev_period) {
+irq_delivered = update_irq(t, 1);
+if (irq_delivered) {
+t-ticks_not_accounted -= t-prev_period;
+t-prev_period = t-period;
+} else {
+if (irq_count) {
+t-irq_rate++;
+t-irq_rate = MIN(t-irq_rate, MAX_IRQ_RATE);
+}
+}
+}
Re: [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts
On Tue, May 03, 2011 at 07:08:25PM -0300, Glauber Costa wrote:
On Tue, 2011-05-03 at 16:03 -0300, Marcelo Tosatti wrote:
On Thu, Apr 28, 2011 at 04:25:00PM +0200, Ulrich Obergfell wrote:
Loss of periodic timer interrupts caused by delayed callbacks and by
interrupt coalescing is compensated by gradually injecting additional
interrupts during subsequent timer intervals, starting at a rate of
one additional interrupt per interval. The injection of additional
interrupts is based on a backlog of unaccounted HPET clock periods
(new HPETTimer field 'ticks_not_accounted'). The backlog increases
due to delayed callbacks and coalesced interrupts, and it decreases
if an interrupt was injected successfully. If the backlog increases
while compensation is still in progress, the rate at which additional
interrupts are injected is increased too. A limit is imposed on the
backlog and on the rate.
Injecting additional timer interrupts to compensate lost interrupts
can alleviate long term time drift. However, on a short time scale,
this method can have the side effect of making virtual machine time
intermittently pass slower and faster than real time (depending on
the guest's time keeping algorithm). Compensation is disabled by
default and can be enabled for guests where this behaviour may be
acceptable.
Signed-off-by: Ulrich Obergfell uober...@redhat.com
---
hw/hpet.c | 63
+++-
1 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 35466ae..92d5f58 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -32,6 +32,7 @@
#include sysbus.h
#include mc146818rtc.h
#include sysemu.h
+#include assert.h
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -42,6 +43,9 @@
#define HPET_MSI_SUPPORT0
+#define MAX_TICKS_NOT_ACCOUNTED (uint64_t)5 /* 5 sec */
+#define MAX_IRQ_RATE(uint32_t)10
+
struct HPETState;
typedef struct HPETTimer { /* timers */
uint8_t tn; /*timer number*/
@@ -326,28 +330,63 @@ static const VMStateDescription vmstate_hpet = {
}
};
+static bool hpet_timer_has_tick_backlog(HPETTimer *t)
+{
+uint64_t backlog = t-ticks_not_accounted - (t-period +
t-prev_period);
+return (backlog = t-period);
+}
+
/*
* timer expiration callback
*/
static void hpet_timer(void *opaque)
{
HPETTimer *t = opaque;
+HPETState *s = t-state;
uint64_t diff;
-
+int irq_delivered = 0;
+uint32_t irq_count = 0;
uint64_t period = t-period;
uint64_t cur_tick = hpet_get_ticks(t-state);
+if (s-driftfix !t-ticks_not_accounted) {
+t-ticks_not_accounted = t-prev_period = t-period;
+}
if (timer_is_periodic(t) period != 0) {
if (t-config HPET_TN_32BIT) {
while (hpet_time_after(cur_tick, t-cmp)) {
t-cmp = (uint32_t)(t-cmp + t-period);
+t-ticks_not_accounted += t-period;
+irq_count++;
}
} else {
while (hpet_time_after64(cur_tick, t-cmp)) {
t-cmp += period;
+t-ticks_not_accounted += period;
+irq_count++;
}
}
diff = hpet_calculate_diff(t, cur_tick);
+if (s-driftfix) {
+if (t-ticks_not_accounted MAX_TICKS_NOT_ACCOUNTED) {
+t-ticks_not_accounted = t-period + t-prev_period;
+}
+if (hpet_timer_has_tick_backlog(t)) {
+if (t-irq_rate == 1 || irq_count 1) {
+t-irq_rate++;
+t-irq_rate = MIN(t-irq_rate, MAX_IRQ_RATE);
+}
+if (t-divisor == 0) {
+assert(irq_count);
+}
+if (irq_count) {
+t-divisor = t-irq_rate;
+}
+diff /= t-divisor--;
+} else {
+t-irq_rate = 1;
+}
+}
qemu_mod_timer(t-qemu_timer,
qemu_get_clock_ns(vm_clock) +
(int64_t)ticks_to_ns(diff));
} else if (t-config HPET_TN_32BIT !timer_is_periodic(t)) {
@@ -358,7 +397,22 @@ static void hpet_timer(void *opaque)
t-wrap_flag = 0;
}
}
-update_irq(t, 1);
+if (s-driftfix timer_is_periodic(t) period != 0) {
+if (t-ticks_not_accounted = t-period + t-prev_period) {
^^
+irq_delivered = update_irq(t, 1);
+if (irq_delivered) {
+t-ticks_not_accounted -= t-prev_period;
+
Re: [Autotest] [AUTOTEST][KVM] [PATCH 2/2] Add ability to call autotest client tests from kvm tests like a subtest.
Hi Jiri, after reviewing the code I have comments, similar to Cleber's:
On Fri, Apr 29, 2011 at 10:59 AM, Jiří Župka jzu...@redhat.com wrote:
Example run autotest/client/netperf2 like a server.
... snip
diff --git a/client/tests/kvm/tests/subtest.py
b/client/tests/kvm/tests/subtest.py
new file mode 100644
index 000..3b546dc
--- /dev/null
+++ b/client/tests/kvm/tests/subtest.py
@@ -0,0 +1,43 @@
+import os, logging
+from autotest_lib.client.virt import virt_utils, virt_test_utils, kvm_monitor
+from autotest_lib.client.bin import job
+from autotest_lib.client.bin.net import net_utils
+
+
+def run_subtest(test, params, env):
+
+ Run an autotest test inside a guest and subtest on host side.
+ This test should be substitution netperf test in kvm.
+
+ @param test: kvm test object.
+ @param params: Dictionary with test parameters.
+ @param env: Dictionary with the test environment.
+
+ vm = env.get_vm(params[main_vm])
+ vm.verify_alive()
+ timeout = int(params.get(login_timeout, 360))
+ session = vm.wait_for_login(timeout=timeout)
+
+ # Collect test parameters
+ timeout = int(params.get(test_timeout, 300))
+ control_path = os.path.join(test.bindir, autotest_control,
+ params.get(test_control_file))
+ control_args = params.get(test_control_args)
+ outputdir = test.outputdir
+
+ guest_ip = vm.get_address()
+ host_ip = net_utils.network().get_corespond_local_ip(guest_ip)
+ if not host_ip is None:
+ control_args = host_ip + + guest_ip
+
+ guest = virt_utils.Thread(virt_test_utils.run_autotest,
+ (vm, session, control_path, control_args,
+ timeout, outputdir, params))
+ guest.start()
+
+ test.runsubtest(netperf2, tag=server, server_ip=host_ip,
+ client_ip=guest_ip, role='server')
^ This really should be made generic, since as Cleber mentioned,
calling this test run_subtest wouldn't cut for cases where we run
something other than netperf2. So things that started coming to my
mind:
* We could extend the utility function to run autotest tests on a
guest in a way that it can accept a string with the control file
contents, rather than just an existing control file. This way we'd be
more free to run arbitrary control code in guests, while of course
keeping the ability to use existing control files;
* We could actually create an Autotest() class abstraction, very much
like what we have in server control files, such as
auto_vm1 = virt_utils.Autotest(vm1) # This would install autotest in a
VM and wait for further commands
control = job.run_test('sleeptest')
auto_vm1.run_control(control) # This would run sleeptest and bring
back the results to the host
It's a matter to see how this is modeled for server side control
files... I believe this could be cleaner and help us a lot...
In other comments, please use the idiom:
if foo is not None:
Across all places where we compare a variable with None, because it's
easier to understand the intent right away and it's on the
CODING_STYLE document.
--
Lucas
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] KVM-test: Add qemu-ifup-atbr0
'atbr0' is a private bridge.
This script is used to setup tap device.
Signed-off-by: Amos Kong ak...@redhat.com
---
client/tests/kvm/scripts/qemu-ifup-atbr0 |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100755 client/tests/kvm/scripts/qemu-ifup-atbr0
diff --git a/client/tests/kvm/scripts/qemu-ifup-atbr0
b/client/tests/kvm/scripts/qemu-ifup-atbr0
new file mode 100755
index 000..82c7efa
--- /dev/null
+++ b/client/tests/kvm/scripts/qemu-ifup-atbr0
@@ -0,0 +1,6 @@
+#!/bin/sh
+switch=atbr0
+/sbin/ifconfig $1 0.0.0.0 up
+/usr/sbin/brctl addif ${switch} $1
+/usr/sbin/brctl setfd ${switch} 0
+/usr/sbin/brctl stp ${switch} off
--
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/2] KVM-test: Setup private bridge in framework
KVM users always use bridge network, there are also some limits in userspace
network, and userspace network is not officially supported by some companys.
Framework will clean configuration when private bridge is not used.
We can replace user net with private bridge if this setup is stable and
general enough.
Configure parameters:
bridge = private
priv_brname = atbr0
priv_subnet = 192.168.58
nic_script = scripts/qemu-ifup-atbr0
Signed-off-by: Amos Kong ak...@redhat.com
---
0 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/client/virt/virt_env_process.py b/client/virt/virt_env_process.py
index 625b422..d2c38f3 100644
--- a/client/virt/virt_env_process.py
+++ b/client/virt/virt_env_process.py
@@ -196,6 +196,28 @@ def preprocess(test, params, env):
@param env: The environment (a dict-like object).
error.context(preprocessing)
+
+if params.get(bridge) == private:
+priv_brname = params.get(priv_brname, 'atbr0')
+priv_subnet = params.get(priv_subnet, '192.168.58')
+if priv_brname not in commands.getoutput(btctl show):
+logging.info(Setup private bridge: %s % priv_brname)
+commands.getoutput(brctl addbr %s % priv_brname)
+file(/proc/sys/net/ipv4/ip_forward, w).write(1\n)
+commands.getoutput(brctl stp %s on % priv_brname)
+commands.getoutput(brctl setfd %s 0 % priv_brname)
+commands.getoutput(ifconfig %s %s.1 up % (priv_brname,
+priv_subnet))
+commands.getoutput(iptables -t nat -A POSTROUTING -s %s.254/24 !
+ -d %s.254/24 -j MASQUERADE % (priv_subnet, priv_subnet))
+commands.getoutput(service dnsmasq stop)
+commands.getoutput(dnsmasq --strict-order --bind-interfaces
+ --listen-address %s.1 --dhcp-range %s.1,%s.254
+ --pid-file=/tmp/dnsmasq.pid %
+(priv_subnet, priv_subnet, priv_subnet))
+if priv_brname not in commands.getoutput(brctl show):
+raise error.TestError(Fail to setup private bridge.)
+
# Start tcpdump if it isn't already running
if address_cache not in env:
env[address_cache] = {}
@@ -365,6 +387,18 @@ def postprocess(test, params, env):
int(params.get(post_command_timeout, 600)),
params.get(post_command_noncritical) == yes)
+if params.get(bridge) == private:
+priv_brname = params.get(priv_brname, 'atbr0')
+priv_subnet = params.get(priv_subnet, '192.168.58')
+if len(commands.getoutput(brctl show|grep %s %
+ priv_brname).split()) 4:
+logging.info(Remove private bridge: %s % priv_brname)
+pid = file(/tmp/dnsmasq.pid).read()
+os.kill(int(pid), 9)
+commands.getoutput(ifconfig %s down % priv_brname)
+commands.getoutput(brctl delbr %s % priv_brname)
+commands.getoutput(iptables -t nat -D POSTROUTING -s %s.254/24 !
+ -d %s.254/24 -j MASQUERADE % (priv_subnet, priv_subnet))
def postprocess_on_error(test, params, env):
--
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 1/2] KVM-test: Add qemu-ifup-atbr0
On 05/04/2011 11:01 AM, Amos Kong wrote:
'atbr0' is a private bridge.
This script is used to setup tap device.
Signed-off-by: Amos Kong ak...@redhat.com
---
client/tests/kvm/scripts/qemu-ifup-atbr0 |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100755 client/tests/kvm/scripts/qemu-ifup-atbr0
diff --git a/client/tests/kvm/scripts/qemu-ifup-atbr0
b/client/tests/kvm/scripts/qemu-ifup-atbr0
new file mode 100755
index 000..82c7efa
--- /dev/null
+++ b/client/tests/kvm/scripts/qemu-ifup-atbr0
@@ -0,0 +1,6 @@
+#!/bin/sh
+switch=atbr0
+/sbin/ifconfig $1 0.0.0.0 up
+/usr/sbin/brctl addif ${switch} $1
+/usr/sbin/brctl setfd ${switch} 0
+/usr/sbin/brctl stp ${switch} off
brctl is not in /usr/sbin but /sbin in some systems, e.g. Debian.
hj:~# which brctl
/sbin/brctl
Does dropping this absolute path to brctl sound better?
--
Best Regards,
Asias He
--
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 1/2] KVM-test: Add qemu-ifup-atbr0
On Wed, 2011-05-04 at 11:11 +0800, Asias He wrote:
On 05/04/2011 11:01 AM, Amos Kong wrote:
'atbr0' is a private bridge.
This script is used to setup tap device.
Signed-off-by: Amos Kong ak...@redhat.com
---
client/tests/kvm/scripts/qemu-ifup-atbr0 |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100755 client/tests/kvm/scripts/qemu-ifup-atbr0
diff --git a/client/tests/kvm/scripts/qemu-ifup-atbr0
b/client/tests/kvm/scripts/qemu-ifup-atbr0
new file mode 100755
index 000..82c7efa
--- /dev/null
+++ b/client/tests/kvm/scripts/qemu-ifup-atbr0
@@ -0,0 +1,6 @@
+#!/bin/sh
+switch=atbr0
+/sbin/ifconfig $1 0.0.0.0 up
+/usr/sbin/brctl addif ${switch} $1
+/usr/sbin/brctl setfd ${switch} 0
+/usr/sbin/brctl stp ${switch} off
brctl is not in /usr/sbin but /sbin in some systems, e.g. Debian.
hj:~# which brctl
/sbin/brctl
Does dropping this absolute path to brctl sound better?
I was planning to revive Jason's patchset that replaced the qemu ifup
scripts altogether. If the scripts were to be kept, yes, dropping the
absolute path sound good.
Thanks!
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 V2] kvm tools: Fix virt_queue__set_used_elem
On Tue, 2011-05-03 at 22:47 +0200, Ingo Molnar wrote: * Sasha Levin levinsasha...@gmail.com wrote: Increase idx only after updating the used element. Not doing so may mark a buffer as used without having it's head and length updated. Signed-off-by: Sasha Levin levinsasha...@gmail.com --- tools/kvm/virtio.c | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/tools/kvm/virtio.c b/tools/kvm/virtio.c index 6249521..266a1b6 100644 --- a/tools/kvm/virtio.c +++ b/tools/kvm/virtio.c @@ -1,15 +1,32 @@ #include linux/virtio_ring.h #include stdint.h #include sys/uio.h +#include asm/system.h If this system.h is included from the current kernel (and not from the system's) then: Acked-by: Ingo Molnar mi...@elte.hu The system.h that'll get picked up is '../../arch/$(ARCH)/include/asm/system.h' within the current kernel tree and not the system one. Thanks, Ingo -- Sasha. -- 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] KVM test: installer: Fix KojiInstaller bug
That code was not updated during the last version of the
refactor patches, so it was referencing the old KojiDownloader
class. Let's fix this.
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/virt/kvm_installer.py | 63 ++---
1 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/client/virt/kvm_installer.py b/client/virt/kvm_installer.py
index dc1ffce..54829f4 100644
--- a/client/virt/kvm_installer.py
+++ b/client/virt/kvm_installer.py
@@ -353,7 +353,9 @@ class YumInstaller(BaseInstaller):
class KojiInstaller(YumInstaller):
Class that handles installing KVM from the fedora build service, koji.
-It uses yum to install and remove packages.
+
+It uses yum to install and remove packages. Packages are specified
+according to the syntax defined in the PkgSpec class.
load_stock_modules = True
def set_install_params(self, test, params):
@@ -364,27 +366,37 @@ class KojiInstaller(YumInstaller):
@param params: Dictionary with test arguments
super(KojiInstaller, self).set_install_params(test, params)
-default_koji_cmd = '/usr/bin/koji'
-default_src_pkg = 'qemu'
-self.src_pkg = params.get(src_pkg, default_src_pkg)
self.tag = params.get(koji_tag, None)
-self.build = params.get(koji_build, None)
-self.koji_cmd = params.get(koji_cmd, default_koji_cmd)
+self.koji_cmd = params.get(koji_cmd, None)
+if self.tag is not None:
+virt_utils.set_default_koji_tag(self.tag)
+self.koji_pkgs = eval(params.get(koji_pkgs, []))
def _get_packages(self):
Downloads the specific arch RPMs for the specific build name.
-downloader = virt_utils.KojiDownloader(cmd=self.koji_cmd)
-downloader.get(src_package=self.src_pkg, tag=self.tag,
-build=self.build, dst_dir=self.srcdir)
+koji_client = virt_utils.KojiClient(cmd=self.koji_cmd)
+for pkg_text in self.koji_pkgs:
+pkg = virt_utils.KojiPkgSpec(pkg_text)
+if pkg.is_valid():
+koji_client.get_pkgs(pkg, dst_dir=self.srcdir)
+else:
+logging.error('Package specification (%s) is invalid: %s', pkg,
+ pkg.describe_invalid())
+
+
+def _clean_previous_installs(self):
+kill_qemu_processes()
+removable_packages = .join(self._get_rpm_names())
+utils.system(yum -y remove %s % removable_packages)
def install(self):
-super(KojiInstaller, self)._clean_previous_installs()
+self._clean_previous_installs()
self._get_packages()
-super(KojiInstaller, self)._install_packages()
+self._install_packages()
self.install_unittests()
create_symlinks(test_bindir=self.test_bindir,
bin_list=self.qemu_bin_paths,
@@ -394,6 +406,35 @@ class KojiInstaller(YumInstaller):
virt_installer.save_build(self.srcdir, self.results_dir)
+def _get_rpm_names(self):
+all_rpm_names = []
+koji_client = virt_utils.KojiClient(cmd=self.koji_cmd)
+for pkg_text in self.koji_pkgs:
+pkg = virt_utils.KojiPkgSpec(pkg_text)
+rpm_names = koji_client.get_pkg_rpm_names(pkg)
+all_rpm_names += rpm_names
+return all_rpm_names
+
+
+def _get_rpm_file_names(self):
+all_rpm_file_names = []
+koji_client = virt_utils.KojiClient(cmd=self.koji_cmd)
+for pkg_text in self.koji_pkgs:
+pkg = virt_utils.KojiPkgSpec(pkg_text)
+rpm_file_names = koji_client.get_pkg_rpm_file_names(pkg)
+all_rpm_file_names += rpm_file_names
+return all_rpm_file_names
+
+
+def _install_packages(self):
+
+Install all downloaded packages.
+
+os.chdir(self.srcdir)
+rpm_file_names = .join(self._get_rpm_file_names())
+utils.system(yum --nogpgcheck -y localinstall %s % rpm_file_names)
+
+
class SourceDirInstaller(BaseInstaller):
Class that handles building/installing KVM directly from a tarball or
--
1.7.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
[PATCH] HTML report: Handle errors when trying to determine test length
Some test like operations (like a kernel booting), the status
log does not contain test lenght info. So handle accordingly
and mark on report as 'Unknown'.
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tools/html_report.py | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/client/tools/html_report.py b/client/tools/html_report.py
index 7b17a75..c4e97b2 100755
--- a/client/tools/html_report.py
+++ b/client/tools/html_report.py
@@ -1572,10 +1572,13 @@ def parse_result(dirname, line):
result['log'] = get_exec_log(dirname, tag)
if len(stimelist)0:
pair = parts[4].split('=')
-etime = int(pair[1])
-stime = stimelist.pop()
-total_exec_time_sec = etime - stime
-result['exec_time_sec'] = total_exec_time_sec
+try:
+etime = int(pair[1])
+stime = stimelist.pop()
+total_exec_time_sec = etime - stime
+result['exec_time_sec'] = total_exec_time_sec
+except ValueError:
+result['exec_time_sec'] = Unknown
return result
return None
--
1.7.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 6/6] KVM: PPC: Add kvm headers to headers_install
On 03.05.2011, at 18:20, Scott Wood wrote: On Tue, 3 May 2011 17:14:48 +0200 Alexander Graf ag...@suse.de wrote: Ah, there it is. I find makefiles very hard to read :). No idea why it worked for you. I can certainly run make headers_install on a ppc machine later today and see if it magically started working on current master. :) I've beet getting ppc asm/kvm.h using headers_install for a while now. Look at the top of include/asm-generic/Kbuild.asm Hum. I just tried again and really do get the headers. I wonder why it didn't work for me before? Either way, I'll drop the patch :). Thanks guys! Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
