Re: [kvm-devel] loop in copy_user_generic_string
2008/3/5, Avi Kivity <[EMAIL PROTECTED]>: > Andi Kleen wrote: > > Avi Kivity <[EMAIL PROTECTED]> writes: > > > >> Most likely movs emulation is broken for long counts. Please post a > >> disassembly of copy_user_generic_string to make sure we're looking at > >> the same code. > >> > > > > Be careful -- this code is patched at runtime and what you > > see in the vmlinux is not necessarily the same that is executed > > > > > > > If the disassembled instruction isn't marked as an alternative in the > source, then it can't be patched, right? > > > > > Incidentially that might cause problems. > > > Specific to kvm? how? > As for me - I'm note sure were this bug come from - I just can easily reproduce it on my box with Qemu-kvm - the problem could be also directly in kernel - (either MMU or dm) - I just know the bug is not reproducible with vmware nor natively running code. On the other hand Qemu-kvm easily catches racing bugs compared with native execution - so maybe it's exposing some MMU problem. I've traced the problem to the instruction place - but I'm not sure how to help more with this issue - so if anyone has some idea what else should I check - let me know. I've got an idea to replace rep movqs with plain asm loop - does anyone thinks it might be worth to check this ?? Zdenek PS: In the attachment there is my config file - thought there is probably nothing special config.bz2 Description: BZip2 compressed data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM Test result, kernel 168676c.., userspace efada39.. 3 issues fixed
Hi All, This is today's KVM test result against kvm.git 168676c978243d14263f900ba35e3534659a68df and kvm-userspace.git efada398f0aaeeaa521379c67be43d597367fce0. Three issues have fixed: 1. blue screen when booting 64bits windows guests https://sourceforge.net/tracker/index.php?func=detail&aid=1906751&group_id=180599&atid=893831 2. Can not boot guests with 2.6.9 smp pae kernel https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1903732&group_id=180599 3. Fails to save/restore guests https://sourceforge.net/tracker/index.php?func=detail&aid=1824525&group_id=180599&atid=893831 Four old issues: 1. qcow based smp linux guests likely hang https://sourceforge.net/tracker/index.php?func=detail&aid=1901980&group_id=180599&atid=893831 2. smp windows installer crashes while rebooting https://sourceforge.net/tracker/index.php?func=detail&aid=1877875&group_id=180599&atid=893831 3. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1826080&group_id=180599 4. Installer of 64bit vista guest will pause for ten minutes after reboot https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1836905&group_id=180599 Test environment PlatformWoodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallelPASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled PASS 7. boot Windows xp with ACPI enabled PASS 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guestPASS 10. LTP on SMP linux guest PASS 11. boot base kernel linux PASS 12. save/restore 32-bit HVM guests PASS 13. live migration 32-bit HVM guests PASS 14. boot SMP Windows xp with ACPI enabledPASS 15. boot SMP Windows 2003 with ACPI enabled PASS 16. boot SMP Windows 2000 with ACPI enabled PASS IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallelPASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallelPASS 11. boot four 32-bit different guest in paraPASS 12. save/restore 64-bit linux guests PASS 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabledPASS 16. boot 32-bit SMP Windows xp with ACPI enabledPASS 17. boot 32-bit Windows 2000 without ACPIPASS 18. boot 64-bit Windows xp with ACPI enabledPASS 19. boot 32-bit Windows xp without ACPIPASS 20. boot 64-bit UP vista PASS 21. boot 64-bit SMP vista FAIL 22. kernel build in 32-bit linux guest OS PASS 23. kernel build in 64-bit linux guest OS PASS 24. LTP on SMP 32-bit linux guest OSPASS 25. LTP on SMP 64-bit linux guest OSPASS 26. boot 64-bit guests with ACPI enabled PASS 27. boot 32-bit x-server PASS 28. boot 64-bit SMP windows XP with ACPI enabled PASS 29. boot 64-bit SMP windows 2003 with ACPI enabled PASS 30. live migration 64bit linux guests PASS 31. live migration 32bit linux guests PASS Report Summary on IA32-pae Summary Test Report of Last Session ===
Re: [kvm-devel] [PATCH 1/6] KVM: In kernel pit model
* Yang, Sheng <[EMAIL PROTECTED]> wrote:
> +#if 1
> +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
> +#else
> +#define pit_debug(fmt, arg...)
> +#endif
this should use pr_debug() instead i guess.
> +#ifndef CONFIG_X86_64
> +#define mod_64(x, y) ((x) - (y) * div64_64(x, y))
> +#else
> +#define mod_64(x, y) ((x) % (y))
> +#endif
> +/* Compute with 96 bit intermediate result: (a*b)/c */
> +static u64 muldiv64(u64 a, u32 b, u32 c)
> +{
> + union {
> + u64 ll;
> + struct {
> + u32 low, high;
> + } l;
> + } u, res;
> + u64 rl, rh;
> +
> + u.ll = a;
> + rl = (u64)u.l.low * (u64)b;
> + rh = (u64)u.l.high * (u64)b;
> + rh += (rl >> 32);
> + res.l.high = div64_64(rh, c);
> + res.l.low = div64_64(((mod_64(rh, c) << 32) + (rl & 0x)), c);
> + return res.ll;
> +}
eventually these should move into a generic file, for example
lib/div64.c.
> + ASSERT(mutex_is_locked(&kvm->arch.vpit->pit_state.lock));
could we please standardize on WARN_ON(!(x)) instead?
> +static enum hrtimer_restart pit_timer_fn(struct hrtimer *data)
> +{
> + struct kvm_kpit_state *ps;
> + int restart_timer = 0;
> +
> + ps = container_of(data, struct kvm_kpit_state, pit_timer.timer);
> +
> + restart_timer = __pit_timer_fn(ps);
> +
> + if (restart_timer)
> + return HRTIMER_RESTART;
> + else
> + return HRTIMER_NORESTART;
> +}
elegant use of hrtimers! :-)
> + if (val == 0)
> + val = 0x1;
magic constant.
> + val &= 0xff;
> + addr &= 3;
magic constants.
Ingo
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH/RFC 1/2] anon-inodes: Remove fd_install() from anon_inode_getfd()
Davide Libenzi wrote:
>> I think that may be a bit cleaner than Al's approach, but it still
>> leaves the same trap that create_vcpu_fd() falls into. The current
>> code is:
>>
>> static int create_vcpu_fd(struct kvm_vcpu *vcpu)
>> {
>> int fd, r;
>> struct inode *inode;
>> struct file *file;
>>
>> r = anon_inode_getfd(&fd, &inode, &file,
>> "kvm-vcpu", &kvm_vcpu_fops, vcpu);
>> if (r)
>> return r;
>> atomic_inc(&vcpu->kvm->filp->f_count);
>> return fd;
>> }
>>
>> and with your proposal, the natural way to write that becomes:
>>
>> static int create_vcpu_fd(struct kvm_vcpu *vcpu)
>> {
>> int fd, r;
>>
>> r = anon_inode_getfd(&fd, NULL,
>> "kvm-vcpu", &kvm_vcpu_fops, vcpu);
>> if (r)
>> return r;
>> atomic_inc(&vcpu->kvm->filp->f_count);
>> return fd;
>> }
>>
>
> I don't know KVM code, but can't the "private_data" setup be completed
> before calling anon_inode_getfd()?
>
Creating the fd is the last thing done when creating a vcpu.
> Or ...
>
> static int create_vcpu_fd(struct kvm_vcpu *vcpu)
> {
> int fd, r;
>
> get_file(vcpu->kvm->filp);
> r = anon_inode_getfd(&fd, NULL,
>"kvm-vcpu", &kvm_vcpu_fops, vcpu);
> if (r) {
> fput(vcpu->kvm->filp);
> return r;
> }
> return fd;
> }
>
This seems reasonable.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Notifier for Externally Mapped Memory (EMM)
On Wed, Mar 05, 2008 at 07:09:55AM +0200, Avi Kivity wrote: > Isn't that out of the question for .25? I keep hearing this mantra. What is so compelling about the .25 release? When seems to be more important than what. While I understand product release cycles, etc. and can certainly agree with them. I would like to know with what I am being asked to agree. That said, I agree we should probably finish getting the comments on Andrea's most recent patch, if any, cleared up and put that one in. Robin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Notifier for Externally Mapped Memory (EMM)
Robin Holt wrote: > On Wed, Mar 05, 2008 at 07:09:55AM +0200, Avi Kivity wrote: > >> Isn't that out of the question for .25? >> > > I keep hearing this mantra. What is so compelling about the .25 > release? When seems to be more important than what. While I understand > product release cycles, etc. and can certainly agree with them. I would > like to know with what I am being asked to agree. > > kvm gained the ability to swap in 2.6.25. Without mmu notifiers, though, the guest can still easily pin all of its memory. > That said, I agree we should probably finish getting the comments on > Andrea's most recent patch, if any, cleared up and put that one in. > Great. Thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
On Tue, 2008-03-04 at 18:50 -0600, Anthony Liguori wrote: > Dor Laor wrote: > > On Tue, 2008-03-04 at 09:52 -0600, Anthony Liguori wrote: > > > >> Yang, Sheng wrote: > >> > >>> Hi > >>> > >>> Here is the last in-kernel PIT patch for KVM. The mainly change from last > >>> version is the supporting to save/restore. I also tested live migration. > >>> > >>> The other modifies including some date structure changed to be better for > >>> supporting the save/restore. I moved the PIT timer to outside of channel > >>> structure, which explicitly means only one channel (channel 0) would > >>> trigger > >>> it. > >>> > >>> After fix TSC problem on SMP PAE RHEL5/5.1 guest, now the patch works > >>> well > >>> without any modify of kernel parameter. > >>> > >>> > >> How are you measuring the improvements from an in-kernel PIT? From your > >> mails, you're claiming it increases the timer accuracy. How are you > >> measuring it and how much does it improve it? > >> > >> > > > > It's also a functionality addition: userspace pit & pic combination > > needed to use -tdf option (time drift fix). The tdf took care of pending > > pit irqs and tried to make the guest ack the right number of irqs the > > pit was configured. > > > > I thought there was some discussion about whether -tdf was every useful > in practice? It works. Just try to play a movie in windows standard HAL with and w/o -tdf --no-irq-chip and you'll see the difference. > > > Once we switched to the default in-kernel pic, the userspace pit > > couldn't get the acks from the pit. > > One can see the effect when running multiple guests (windows, standard > > HAL) playing video, the time slows down. > > > > Okay, that makes sense. So have you done any tests to confirm this? We > suffered through a fair number of regressions when we moved to an > in-kernel APIC. Before moving another big chunk of code in the kernel > and going through possible regressions, I want to make sure we have a > measurable argument that it's the right thing to do. > > So how do we measure the benefits of an in-kernel PIT? Play the same movie using the kernel's pit. > > Regards, > > Anthony Liguori > > > This patch set has a pending counter and takes care for it too. > > > > > >> Do you expect an overall performance improvement from this or is it > >> simply about improving timer accuracy? > >> > >> > > > > It will probably help older kernels with slow HZ run faster HZ guests. > > Without CONFIG_DYNTICK the guests behaved jumpy because of that. > > > > > >> Regards, > >> > >> Anthony Liguori > >> > >> > >> > >> - > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > >> ___ > >> kvm-devel mailing list > >> kvm-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/kvm-devel > >> > > > > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel daf4de3. ., userspace 724f8a9.. One new issue
On Tuesday 04 March 2008 17:00:25 Avi Kivity wrote: > Yunfeng Zhao wrote: > > Hi, all, > > > > This is today's KVM test result against kvm.git > > daf4de30ec718b16798aba07e9f25fd9e6ba9e53 and kvm-userspace.git > > 724f8a940ec0e78e607c051e6e82ca2f5055b1e1. > > In today's testing , save/restore crashed host once on pae/ia32e hosts. > > One new issue has been found: > > 1. blue screen when booting 64bits windows guests > > > > https://sourceforge.net/tracker/index.php?func=detail&aid=1906751&group_i > >d=180599&atid=893831 > > This was caused by > > > commit 3a001629eea909b2aa97f001a9db4700f15d986b > Author: Amit Shah <[EMAIL PROTECTED]> > Date: Thu Feb 28 16:06:15 2008 +0530 > > KVM: is_long_mode() should check for EFER.LMA > > is_long_mode currently checks the LongModeEnable bit in > EFER instead of the LongModeActive bit. This is wrong, but > we survived this till now since it wasn't triggered. This > breaks guests that go from long mode to compatibility mode. > > This is noticed on a solaris guest and fixes bug #1842160 > > Signed-off-by: Amit Shah <[EMAIL PROTECTED]> > Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> This only affects Intel platforms; vista, xp64 work fine with and without smp on SVM with this patch. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Notifier for Externally Mapped Memory (EMM)
On Wed, 2008-03-05 at 03:47 -0600, Robin Holt wrote: > On Wed, Mar 05, 2008 at 07:09:55AM +0200, Avi Kivity wrote: > > Isn't that out of the question for .25? > > I keep hearing this mantra. What is so compelling about the .25 > release? When seems to be more important than what. While I understand > product release cycles, etc. and can certainly agree with them. I would > like to know with what I am being asked to agree. > The main reason is that several kvm exciting features are dependent on mmu notifiers: - It enables full guest swapping (as opposed to partial today) - It enables memory ballooning - It enables running Izik Eidus's Kernel Shared Pages module that unify guest pages together. The patchset is kernel-internal, stable and reviewed. Even if the interface will be changed in .26 it won't have noticeable effect. So since its stable, internal, reviewed, needed to enable important kvm features we like to see it in for .25. Regards, Dor > That said, I agree we should probably finish getting the comments on > Andrea's most recent patch, if any, cleared up and put that one in. > > Robin > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/6] KVM: In kernel pit model
Thanks for comments!
On Wednesday 05 March 2008 17:15:29 Ingo Molnar wrote:
> * Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > +#if 1
> > +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
> > +#else
> > +#define pit_debug(fmt, arg...)
> > +#endif
>
> this should use pr_debug() instead i guess.
Um... I followed example on ./virt/kvm/ioapic.c here. Though I think it's good
to substitute all self defined debug printk with pr_debug, why KVM have
little pr_xxx(the only ones are in x86.c)? Maybe for KVM is acting more like
a separate driver, and using printk is easier for separate debug? I really
don't know...
> > +#ifndef CONFIG_X86_64
> > +#define mod_64(x, y) ((x) - (y) * div64_64(x, y))
> > +#else
> > +#define mod_64(x, y) ((x) % (y))
> > +#endif
> >
> > +/* Compute with 96 bit intermediate result: (a*b)/c */
> > +static u64 muldiv64(u64 a, u32 b, u32 c)
> > +{
> > + union {
> > + u64 ll;
> > + struct {
> > + u32 low, high;
> > + } l;
> > + } u, res;
> > + u64 rl, rh;
> > +
> > + u.ll = a;
> > + rl = (u64)u.l.low * (u64)b;
> > + rh = (u64)u.l.high * (u64)b;
> > + rh += (rl >> 32);
> > + res.l.high = div64_64(rh, c);
> > + res.l.low = div64_64(((mod_64(rh, c) << 32) + (rl & 0x)), c);
> > + return res.ll;
> > +}
>
> eventually these should move into a generic file, for example
> lib/div64.c.
That's my hope (of course with big endian support). But is there any user
outside KVM? I think it may not easy to get into the generic part.
> > + ASSERT(mutex_is_locked(&kvm->arch.vpit->pit_state.lock));
>
> could we please standardize on WARN_ON(!(x)) instead?
Sure. :)
> > +static enum hrtimer_restart pit_timer_fn(struct hrtimer *data)
> > +{
> > + struct kvm_kpit_state *ps;
> > + int restart_timer = 0;
> > +
> > + ps = container_of(data, struct kvm_kpit_state, pit_timer.timer);
> > +
> > + restart_timer = __pit_timer_fn(ps);
> > +
> > + if (restart_timer)
> > + return HRTIMER_RESTART;
> > + else
> > + return HRTIMER_NORESTART;
> > +}
>
> elegant use of hrtimers! :-)
>
> > + if (val == 0)
> > + val = 0x1;
>
> magic constant.
>
> > + val &= 0xff;
> > + addr &= 3;
>
> magic constants.
I will update these constants. :) In fact, I have thought of these before, but
not insist...
Thanks!
Yang, Sheng
>
> Ingo
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/6] KVM: In kernel pit model
Yang, Sheng wrote: > Thanks for comments! > > On Wednesday 05 March 2008 17:15:29 Ingo Molnar wrote: > >> * Yang, Sheng <[EMAIL PROTECTED]> wrote: >> >>> +#if 1 >>> +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg) >>> +#else >>> +#define pit_debug(fmt, arg...) >>> +#endif >>> >> this should use pr_debug() instead i guess. >> > > Um... I followed example on ./virt/kvm/ioapic.c here. Though I think it's > good > to substitute all self defined debug printk with pr_debug, why KVM have > little pr_xxx(the only ones are in x86.c)? Maybe for KVM is acting more like > a separate driver, and using printk is easier for separate debug? I really > don't know... > > It's mostly due to lack of knowledge about pr_debug(); it wasn't intentional. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/6] KVM: In kernel pit model
* Yang, Sheng <[EMAIL PROTECTED]> wrote: > > * Yang, Sheng <[EMAIL PROTECTED]> wrote: > > > +#if 1 > > > +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg) > > > +#else > > > +#define pit_debug(fmt, arg...) > > > +#endif > > > > this should use pr_debug() instead i guess. > > Um... I followed example on ./virt/kvm/ioapic.c here. Though I think > it's good to substitute all self defined debug printk with pr_debug, > why KVM have little pr_xxx(the only ones are in x86.c)? Maybe for KVM > is acting more like a separate driver, and using printk is easier for > separate debug? I really don't know... it's just a small detail - it's really not a big issue and my suggestion should be functionally equivalent. What i meant is that with pr_debug() you can remove the pit_debug() define altogether (and change all pit_debug's to pr_debug). In that case all you need to do is to get the printks is to stick this to the head of the source code file (to before the include files): #define DEBUG and the pr_debug() calls turn from a NOP into a printk(KERN_DEBUG,...). Ingo - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/8] RFC: vcpu pinning at qemu start
Anthony Liguori wrote: > Glauber Costa wrote: >> Anthony Liguori wrote: >> >> No, it can't. Because at the time qemu starts, no vcpu -> thread id >> relationship exists at all. And we don't know when it will. > > Sure we do. The vcpu -> thread id relationship is valid after > kvm_init_ap() is called which is after machine init but before the > select loop is entered for the first time. Therefore, if you start qemu > with -S, then connect on the monitor, and do an info cpus, you could be > guaranteed to be told the mapping. I missed that. This changes everything. I now completely agree with you. I'll post patches that expose the relationship, if it's better. > The threads are *idle* at this point so there's no harm if they were > started on the "wrong" CPU. You can now taskset to your hearts content > and then when you're happy with placement, you can issue a 'cont' so > that the VM actually starts running. I saw "wrong" because you can > still taskset the initial creation guaranteeing that the threads are > created on the right group of physical CPUs, you just can't specify the > exact mapping until you start interacting with the monitor. > > Regards, > > Anthony Liguori > >>> Regards, >>> >>> Anthony Liguori >>> >>> >> > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/8] RFC: vcpu pinning at qemu start
Avi Kivity wrote: > Glauber Costa wrote: >> Hi guys, >> >> Here's a first series of patch aiming at vcpu pinning support in qemu. >> Ideally, as vcpu as just normal threads, the usual userspace tools can >> be used >> to set cpu affinities mask. >> >> However, It makes it very difficult to _start_ a vm with vcpus pinned, >> since >> we don't know the thread ids from qemu in advance, nor do we know when >> are the >> vcpus created. >> >> The patches introduce a -cpu-map option, that, if specified, starts >> the virtual cpus >> with the specified affinities. >> >> Comments? Welcome. Random rants? Not welcome, but... how can I stop >> you? So go ahead! >> >> > > A monitor interface would be more useful than a command line option, as > it allows you to migrate the vcpus at runtime, and also control > hotplugged cpus. For unmanaged use, taskset is probably sufficient to > control affinity from the command line. > > Normally I encourage splitting patches, but this is a bit extreme. 1 > and 3 are pointless without each other, 4 and 5, 7 and 8. Hope that > doesn't interfere with any pay-per-patch contract. > I'll post a new series that just expose the thread ids, so the management tools can use plain taskset. As for the split, there's nothing in my contract, but after all the x86 integration, it became a mania for me. Ingo made me this way. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/8] RFC: vcpu pinning at qemu start
Avi Kivity wrote: > Affinity control is probably useful mostly for numa configurations, > where you want to restrict virtual cpus to run on the cores closest to > memory. However it may well be that the scheduler is already good > enough to do this on its own. In that case, you need to use numactl to set a NUMA policy so it's pretty natural that you would also be using taskset. Assuming you're trying to keep a VM local to a particular node (we don't expose a virtual SRAT/SLIT table so that's all we can sanely do right now), it doesn't matter what CPU each VCPU thread lands on as long as they stay within the node. So taskset is perfectly capable to address this need today. > In the brutal world of hypervisors, if your competitor has a feature, > you must have it too. I often get asked about cpu pinning in kvm. And the answer to give is, of course, we support it through taskset :-) Regards, Anthony Liguori > [I'd like to see how Xen implements swapping, though] > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
Dor Laor wrote: > On Tue, 2008-03-04 at 18:50 -0600, Anthony Liguori wrote: > >> Dor Laor wrote: >> >> I thought there was some discussion about whether -tdf was every useful >> in practice? >> > > It works. > Just try to play a movie in windows standard HAL with and w/o -tdf > --no-irq-chip and you'll see the difference. > I don't have a VM with the standard HAL but I'll take your word for it. >> >> So how do we measure the benefits of an in-kernel PIT? >> > > Play the same movie using the kernel's pit. > Playing a movie is a bit subjective. I presume you're talking about the standard HAL as presumably the ACPI HAL is using the pm timer? So the two cases I'm hearing where timer accuracy should improve is standard HAL on Windows and clock=pit on Linux? I'd still like to see what the actual difference in timer accuracy is. I have no doubt that moving the pit into the kernel is more efficient. Moving everything into the kernel is more efficient because light weight exits are cheaper than heavy weight exits. The thing I'm trying to get at is a quantitative statement about why moving the pit into the kernel is the right thing. I'll try to give the patches a try myself in the next couple of days. I don't think it's obvious that it's the right thing to do without some sort of benchmark supporting it. Regards, Anthony LIguori - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] still seeing network freezes with rtl8139 nic
Try adding the noapic option to your guest kernel. I re-ran that test on kvm-62 and my VM was able to run under load for more than 3-1/2 days (the network never locked up; I stopped the test to try other variations). One side effect of the noapic option is that irq balancing is disabled -- all interrupts are delivered via CPU 0. I ran a few tests earlier this week without the noapic option (hence with the apic) but with irq balancing disabled and still had the lockups. It seems to be something specific to the apic. david Eckersid SIlapaswang wrote: > david ahern cisco.com> writes: > >> I know this issue has been discussed on this list before, but I am still >> experiencing network freezes in a guest that requires a restart to clear. >> When >> the network freezes in the guest I no longer see the network interrupts >> counter >> incrementing (i.e., the eth0 counter in /proc/interrupts in the guest). Using >> the crash utility, I verified that the interrupt is still enabled on the >> guest >> side and that no interrupts are pending. This suggests that the interrupts >> are >> not getting delivered to the VM. > > I just wanted to let the developers know that I'm having similar problems > concerning interrupts with networking dying as well. > > Running a stress test of kvm using an EnGarde Secure Linux 1.5 guest OS. > Under a heavy network email load, the guest OS networking gets knocked out > - unable to ping, ssh, etc. Can only get things started again by going > into vncviewer and restarting the networking services from there. > > CPUs: 8 x Intel(R) Xeon(R) CPU E5335 @ 2.00GHz > KVM 52-1 > Host Kernel: 2.6.25-rc2 > Kernel Arch: x86_64 > Guest OS: EnGarde Secure Linux 32bit i686, 2.4.31-1.5.60 > > Command Line: > /usr/bin/qemu-system -hda /root/images/bwimail01.img -boot c -m 384 -smp 4 > -std-vga -net nic,vlan=0,macaddr=52:54:00:12:34:6F -net > tap,ifname=tap1,script=/etc/qemu-ifup -vnc 192.168.1.57:1 & > > Please let me know if you need anymore information and if I could be of any > assistance in providing information to have this issue resolved. > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] I/O bandwidth control on KVM
Hi, > If you are using virtio drivers in the guest (which I presume you are > given the reference to /dev/vda), try using the following -drive syntax: > > -drive file=/dev/mapper/ioband1,if=virtio,boot=on,cache=off > > This will force the use of O_DIRECT. By default, QEMU does not open > with O_DIRECT so you'll see page cache effects. I tried the test with "cache=off" option, here is the result. The number of issued I/Os | device | sda11 | sda12 | | weight setting|80%|20%| |+---+---| | KVM | I/Os | 5217| 5623| | cache=off | ratio to total | 48.1% | 51.9% | |---++---+---| | KVM | I/Os | 4397| 2902| | cache=on | ratio to total | 60.2% | 39.8% | |---++---+---| |local | I/Os | 5447| 1314| | | ratio to total | 80.6% | 19.4% | I could see the page cache effect through the /sys/block/sda/sda[12]/stat, O_DIRECT was taking effect. However, the bandwidth control didn't work. I also did another test. The difference from the previous test is that the weights were assigned on a per partition basis instead of a per cgroup basis. It worked fine on Xen and local processes, but unfortunately it didn't work on KVM. The number of issued I/Os The weights were assigned on a per partition basis | device | sda11 | sda12 | | weight setting|80%|20%| |+---+---| | KVM | I/Os | 5905| 5873| | cache=off | ratio to total | 50.1% | 49.9% | |---++---+---| |local | I/Os | 6929| 1629| | | ratio to total | 81.0% | 19.0% | || | Xen | I/Os | 8534| 2360| | | ratio to total | 78.3% | 21.7% | I don't understand what was going on. I'd be appreciate if you could give me other suggestions. Thanks, Ryo Tsuruta - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
Handle the case where the balloon target is larger than total ram size.
BUG: unable to handle kernel paging request at 00100100
IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: virtio/virtio_balloon.c
===
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -122,10 +122,21 @@ static void release_pages_by_pfn(const u
}
}
+static void update_target_size(struct virtio_balloon *vb)
+{
+ __le32 num_pages = cpu_to_le32(vb->num_pages);
+
+ vb->vdev->config->set(vb->vdev,
+ offsetof(struct virtio_balloon_config, num_pages),
+ &num_pages, sizeof(num_pages));
+}
+
+
static void leak_balloon(struct virtio_balloon *vb, size_t num)
{
struct page *page;
+ num = min_t(unsigned int, vb->num_pages, num);
/* We can only do one array worth at a time. */
num = min(num, ARRAY_SIZE(vb->pfns));
@@ -136,6 +147,12 @@ static void leak_balloon(struct virtio_b
vb->num_pages--;
}
+ /* Have nothing to release? update target accordingly. */
+ if (vb->num_pfns == 0) {
+ update_target_size(vb);
+ return;
+ }
+
if (vb->tell_host_first) {
tell_host(vb, vb->deflate_vq);
release_pages_by_pfn(vb->pfns, vb->num_pfns);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] I/O bandwidth control on KVM
Ryo Tsuruta wrote:
Hi,
If you are using virtio drivers in the guest (which I presume you are
given the reference to /dev/vda), try using the following -drive syntax:
-drive file=/dev/mapper/ioband1,if=virtio,boot=on,cache=off
This will force the use of O_DIRECT. By default, QEMU does not open
with O_DIRECT so you'll see page cache effects.
I tried the test with "cache=off" option, here is the result.
Can you give the attached patch a try? The virtio backend does
synchronous IO requests blocking the guest from making progress until
the IO completes. It's possible that what you're seeing is the
scheduler competing with your IO bandwidth limiting in order to ensure
fairness since IO completion is intimately tied to CPU consumption
(since we're using blocking IO).
The attached patch implements AIO support for the virtio backend so if
this is the case, you should see the proper proportions.
Regards,
Anthony Liguori
diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c
index 301b5a1..3c56bed 100644
--- a/qemu/hw/virtio-blk.c
+++ b/qemu/hw/virtio-blk.c
@@ -71,59 +71,121 @@ typedef struct VirtIOBlock
BlockDriverState *bs;
} VirtIOBlock;
+typedef struct VBDMARequestState VBDMARequestState;
+
+typedef struct VBDMAState
+{
+VirtQueueElement elem;
+int count;
+int is_write;
+unsigned int wlen;
+VirtQueue *vq;
+VirtIODevice *vdev;
+VBDMARequestState *requests;
+} VBDMAState;
+
+struct VBDMARequestState
+{
+VBDMAState *dma;
+BlockDriverAIOCB *aiocb;
+VBDMARequestState *next;
+};
+
static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
{
return (VirtIOBlock *)vdev;
}
+static void virtio_io_completion(void *opaque, int ret)
+{
+VBDMARequestState *req = opaque, **ppreq;
+VBDMAState *dma = req->dma;
+struct virtio_blk_inhdr *in;
+
+for (ppreq = &dma->requests; *ppreq; ppreq = &(*ppreq)->next) {
+ if (*ppreq == req) {
+ *ppreq = req->next;
+ break;
+ }
+}
+
+qemu_free(req);
+
+if (dma->requests)
+ return;
+
+in = (void *)dma->elem.in_sg[dma->elem.in_num - 1].iov_base;
+dma->wlen += sizeof(*in);
+if (ret == -EOPNOTSUPP)
+ in->status = VIRTIO_BLK_S_UNSUPP;
+else
+ in->status = VIRTIO_BLK_S_OK;
+virtqueue_push(dma->vq, &dma->elem, dma->wlen);
+virtio_notify(dma->vdev, dma->vq);
+qemu_free(dma);
+}
+
static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIOBlock *s = to_virtio_blk(vdev);
-VirtQueueElement elem;
+VBDMAState *dma = qemu_mallocz(sizeof(VBDMAState));
unsigned int count;
-while ((count = virtqueue_pop(vq, &elem)) != 0) {
- struct virtio_blk_inhdr *in;
+while ((count = virtqueue_pop(vq, &dma->elem)) != 0) {
struct virtio_blk_outhdr *out;
- unsigned int wlen;
+ VBDMARequestState *req;
off_t off;
int i;
- out = (void *)elem.out_sg[0].iov_base;
- in = (void *)elem.in_sg[elem.in_num - 1].iov_base;
+ out = (void *)dma->elem.out_sg[0].iov_base;
off = out->sector;
+ dma->vq = vq;
+ dma->vdev = vdev;
+
if (out->type & VIRTIO_BLK_T_SCSI_CMD) {
- wlen = sizeof(*in);
- in->status = VIRTIO_BLK_S_UNSUPP;
+ req = qemu_mallocz(sizeof(VBDMARequestState));
+ req->dma = dma;
+ req->next = dma->requests;
+ dma->requests = req;
+ virtio_io_completion(req, -EOPNOTSUPP);
} else if (out->type & VIRTIO_BLK_T_OUT) {
- wlen = sizeof(*in);
-
- for (i = 1; i < elem.out_num; i++) {
- bdrv_write(s->bs, off,
- elem.out_sg[i].iov_base,
- elem.out_sg[i].iov_len / 512);
- off += elem.out_sg[i].iov_len / 512;
+ dma->count = dma->elem.out_num - 1;
+ dma->is_write = 1;
+ for (i = 1; i < dma->elem.out_num; i++) {
+ req = qemu_mallocz(sizeof(VBDMARequestState));
+ req->dma = dma;
+ req->next = dma->requests;
+ dma->requests = req;
+
+ req->aiocb = bdrv_aio_write(s->bs, off,
+ dma->elem.out_sg[i].iov_base,
+ dma->elem.out_sg[i].iov_len / 512,
+ virtio_io_completion, req);
+ off += dma->elem.out_sg[i].iov_len / 512;
}
-
- in->status = VIRTIO_BLK_S_OK;
} else {
- wlen = sizeof(*in);
-
- for (i = 0; i < elem.in_num - 1; i++) {
- bdrv_read(s->bs, off,
- elem.in_sg[i].iov_base,
- elem.in_sg[i].iov_len / 512);
- off += elem.in_sg[i].iov_len / 512;
- wlen += elem.in_sg[i].iov_len;
+ dma->count = dma->elem.in_num - 1;
+ dma->is_write = 0;
+ for (i = 0; i < dma->elem.in_num - 1; i++) {
+ req = qemu_mallocz(sizeof(VBDMARequestState));
+ req->dma = dma;
+ req->next = dma->requests;
+ dma->requests = req;
+
+ req->aiocb = bdrv_aio_read(s->bs, off,
+ dma->elem.in_sg[i].iov_base,
+ dma->elem.in_sg[i].iov_len / 512,
+ virtio_io_completion, req);
+ off += dma->elem.in_sg[i].iov_len / 512;
+ dma->wlen += dma->elem.in_sg[i].iov_len;
}
-
- in->status = VIRTIO_BLK_S_OK;
}
- virtqueue_push(vq, &elem, wlen);
- virtio_notify(vdev, vq);
+ dma = qemu_mallocz(sizeof(VBDMAState));
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
Marcelo Tosatti wrote:
> Handle the case where the balloon target is larger than total ram size.
>
> BUG: unable to handle kernel paging request at 00100100
> IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
>
> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>
> Index: virtio/virtio_balloon.c
> ===
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -122,10 +122,21 @@ static void release_pages_by_pfn(const u
> }
> }
>
> +static void update_target_size(struct virtio_balloon *vb)
> +{
> + __le32 num_pages = cpu_to_le32(vb->num_pages);
> +
> + vb->vdev->config->set(vb->vdev,
> + offsetof(struct virtio_balloon_config, num_pages),
> + &num_pages, sizeof(num_pages));
> +}
>
The target is host-owned; moreover the problem may be temporary, but
you've changed the target permanently.
Suggest sending the host a message (like the page list) indicating it
couldn't allocate any more.
Also, we may have driven the guest close to oom with this. We need to
notify the host when the guest gets into a low-memory cannot swap condition.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] still seeing network freezes with rtl8139 nic
david ahern wrote: > Try adding the noapic option to your guest kernel. I re-ran that test on > kvm-62 > and my VM was able to run under load for more than 3-1/2 days (the network > never > locked up; I stopped the test to try other variations). > > One side effect of the noapic option is that irq balancing is disabled -- all > interrupts are delivered via CPU 0. I ran a few tests earlier this week > without > the noapic option (hence with the apic) but with irq balancing disabled and > still had the lockups. It seems to be something specific to the apic. > > I got good results with apic and e1000. Can you try it? May be a guest driver bug. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
Anthony Liguori wrote: > Playing a movie is a bit subjective. I presume you're talking about the > standard HAL as presumably the ACPI HAL is using the pm timer? > ACPI HAL uses the apic timer, IIRC; perhaps the pm timer as well. > So the two cases I'm hearing where timer accuracy should improve is > standard HAL on Windows and clock=pit on Linux? I'd still like to see > what the actual difference in timer accuracy is. It depends on the load. As the load increases, the host process starts to miss timer signals. With both pic and pit in userspace, you can detect those missed interrupts and inject them later once you get your timeslice. With the pic in kernel, there is no way to do this. The same thing happens with the apic timer, only there, it is easy to compensate because both parts are in the kernel. > I have no doubt that > moving the pit into the kernel is more efficient. Moving everything > into the kernel is more efficient because light weight exits are cheaper > than heavy weight exits. > Efficiency is only a secondary goal here. The userspace PIT does not consume large amounts of CPU. > The thing I'm trying to get at is a quantitative statement about why > moving the pit into the kernel is the right thing. I'll try to give the > patches a try myself in the next couple of days. I don't think it's > obvious that it's the right thing to do without some sort of benchmark > supporting it. > Playing a movie is better than any benchmark; it reflects actual user experience in a real and important use case. Benchmarks are substitutes for real use cases, not the goal of the optimization. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-62 release
Very Nice. Must be KVM-63. > - merge qemu-cvs >- new curses display option How to activate that one? -- -Alexey Eremenko "Technologov" - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
Marcelo Tosatti wrote:
> On Wed, Mar 05, 2008 at 06:59:10PM +0200, Avi Kivity wrote:
>
>> Marcelo Tosatti wrote:
>>
>>> Handle the case where the balloon target is larger than total ram size.
>>>
>>> BUG: unable to handle kernel paging request at 00100100
>>> IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
>>>
>>> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>>>
>>> Index: virtio/virtio_balloon.c
>>> ===
>>> --- a/drivers/virtio/virtio_balloon.c
>>> +++ b/drivers/virtio/virtio_balloon.c
>>> @@ -122,10 +122,21 @@ static void release_pages_by_pfn(const u
>>> }
>>> }
>>>
>>> +static void update_target_size(struct virtio_balloon *vb)
>>> +{
>>> + __le32 num_pages = cpu_to_le32(vb->num_pages);
>>> +
>>> + vb->vdev->config->set(vb->vdev,
>>> + offsetof(struct virtio_balloon_config,
>>> num_pages),
>>> + &num_pages, sizeof(num_pages));
>>> +}
>>>
>>>
>> The target is host-owned; moreover the problem may be temporary, but
>> you've changed the target permanently.
>>
>> Suggest sending the host a message (like the page list) indicating it
>> couldn't allocate any more.
>>
>> Also, we may have driven the guest close to oom with this. We need to
>> notify the host when the guest gets into a low-memory cannot swap condition.
>>
>
> I guess the description was not clear, you understood the opposite.
>
> The problem is when the target for total guest pages (not balloon target
> size) is set to be larger than the amount of total pages the guest has
> booted with. What happens then is that the driver tries to release pages
> from the balloon, without checking if there are any:
>
> static void leak_balloon(struct virtio_balloon *vb, size_t num)
> {
> struct page *page;
>
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
>
> for (vb->num_pfns = 0; vb->num_pfns < num; vb->num_pfns++) {
> page = list_first_entry(&vb->pages, struct page, lru);
> list_del(&page->lru);
> vb->pfns[vb->num_pfns] = page_to_pfn(page);
> vb->num_pages--;
> }
>
> vp->pages is empty here.
>
> So the patch checks for the availability of ballooned pages before
> attempting to release any, and sets num_pages to match that.
>
> The host should not allow that to condition to happen, but its still
> fragile code in the guest driver.
>
>
Ah, I see. We could simply ignore it, or adjust the target as you did.
Not sure what is better.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-62 release
Avi Kivity wrote: > Add cpus on the fly to your virtual machines with the new cpu hotplug > feature. > er, kvm-63, that is. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
On Wed, Mar 05, 2008 at 06:59:10PM +0200, Avi Kivity wrote:
> Marcelo Tosatti wrote:
> >Handle the case where the balloon target is larger than total ram size.
> >
> >BUG: unable to handle kernel paging request at 00100100
> >IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
> >
> >Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
> >
> >Index: virtio/virtio_balloon.c
> >===
> >--- a/drivers/virtio/virtio_balloon.c
> >+++ b/drivers/virtio/virtio_balloon.c
> >@@ -122,10 +122,21 @@ static void release_pages_by_pfn(const u
> > }
> > }
> >
> >+static void update_target_size(struct virtio_balloon *vb)
> >+{
> >+__le32 num_pages = cpu_to_le32(vb->num_pages);
> >+
> >+vb->vdev->config->set(vb->vdev,
> >+ offsetof(struct virtio_balloon_config,
> >num_pages),
> >+ &num_pages, sizeof(num_pages));
> >+}
> >
>
> The target is host-owned; moreover the problem may be temporary, but
> you've changed the target permanently.
>
> Suggest sending the host a message (like the page list) indicating it
> couldn't allocate any more.
>
> Also, we may have driven the guest close to oom with this. We need to
> notify the host when the guest gets into a low-memory cannot swap condition.
I guess the description was not clear, you understood the opposite.
The problem is when the target for total guest pages (not balloon target
size) is set to be larger than the amount of total pages the guest has
booted with. What happens then is that the driver tries to release pages
from the balloon, without checking if there are any:
static void leak_balloon(struct virtio_balloon *vb, size_t num)
{
struct page *page;
/* We can only do one array worth at a time. */
num = min(num, ARRAY_SIZE(vb->pfns));
for (vb->num_pfns = 0; vb->num_pfns < num; vb->num_pfns++) {
page = list_first_entry(&vb->pages, struct page, lru);
list_del(&page->lru);
vb->pfns[vb->num_pfns] = page_to_pfn(page);
vb->num_pages--;
}
vp->pages is empty here.
So the patch checks for the availability of ballooned pages before
attempting to release any, and sets num_pages to match that.
The host should not allow that to condition to happen, but its still
fragile code in the guest driver.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-62 release
Add cpus on the fly to your virtual machines with the new cpu hotplug feature. Changes from kvm-62: - portability: make room for the ia64 register stack (Xiantao Zhang) - fix leak when setting the pv clock to an invalid address (Marcelo Tosatti) - detect vcpu triple faults (Joerg Roedel) - fix race when instantiating a shadow pte - fix host crash on guest kexec - code cleanups (Harvey Harrison) - better tsc handling on Intel hosts with stable tscs - cpu hotplug (Glauber Costa) - merge qemu-cvs - new curses display option - change -hugetlb-path to -mem-path (Anthony Liguori) - increase pci support from 6 slots to 32 slots - document ./configure --disable-cpu-emulation (Jerone Young) - fix powerpc cpu initialization (Jerone Young) - simplify host_cpuid() assembly code Notes: If you use the modules bundled with kvm-63, you can use any version of Linux from 2.6.17 upwards. If you use the modules bundled with Linux 2.6.20, you need to use kvm-12. If you use the modules bundled with Linux 2.6.21, you need to use kvm-17. Modules from Linux 2.6.22 and up will work with any kvm version from kvm-22. Some features may only be available in newer releases. For best performance, use Linux 2.6.23-rc2 or later as the host. http://kvm.qumranet.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] still seeing network freezes with rtl8139 nic
I did not have any better luck with the e1000 or pcnet nics when running kvm-61. I'll try again with kvm-63 and get back to you. david Avi Kivity wrote: > david ahern wrote: >> Try adding the noapic option to your guest kernel. I re-ran that test >> on kvm-62 >> and my VM was able to run under load for more than 3-1/2 days (the >> network never >> locked up; I stopped the test to try other variations). >> >> One side effect of the noapic option is that irq balancing is disabled >> -- all >> interrupts are delivered via CPU 0. I ran a few tests earlier this >> week without >> the noapic option (hence with the apic) but with irq balancing >> disabled and >> still had the lockups. It seems to be something specific to the apic. >> >> > > I got good results with apic and e1000. Can you try it? > > May be a guest driver bug. > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
Avi Kivity wrote:
> Marcelo Tosatti wrote:
>
>> Handle the case where the balloon target is larger than total ram size.
>>
>> BUG: unable to handle kernel paging request at 00100100
>> IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
>>
>> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>>
>> Index: virtio/virtio_balloon.c
>> ===
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
>> @@ -122,10 +122,21 @@ static void release_pages_by_pfn(const u
>> }
>> }
>>
>> +static void update_target_size(struct virtio_balloon *vb)
>> +{
>> +__le32 num_pages = cpu_to_le32(vb->num_pages);
>> +
>> +vb->vdev->config->set(vb->vdev,
>> + offsetof(struct virtio_balloon_config, num_pages),
>> + &num_pages, sizeof(num_pages));
>> +}
>>
>>
>
> The target is host-owned; moreover the problem may be temporary, but
> you've changed the target permanently.
>
> Suggest sending the host a message (like the page list) indicating it
> couldn't allocate any more.
>
This is what the actual field in the config space is meant for.
> Also, we may have driven the guest close to oom with this. We need to
> notify the host when the guest gets into a low-memory cannot swap condition.
>
We need an OOM handler and a high seek-cost shrinker to ensure we do not
go too low I imagine. We can notify the host of when we refuse to go
lower with actual in the config space.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/4] kvmclock fixes
Hi, With this series, I'm introducing the ability to turn off the kvmclock. It is done by writting any thing to the first three bits of the address passed as a parameter to the msr. For that to work properly, we should make absolutely sure the guest is aligned. If we really care about compatibility here, we can set the KVM_CAP_CLOCKSOURCE to 0, and define a new feature flag to mean that the clock data structures should be aligned. However, as the guest part has not yet made its way to linus, we're in a privileged position of having no users other than the experimental users, and can change it withouth bothering so much. /* Comments? */ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/4] [PATCH] kvmclock: release time_page if msr is rewritten
If the calling cpu rewrites the system clock msr for any reason,
release the page we allocated in the last time
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e65a9d6..6abd784 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -588,6 +588,9 @@ int kvm_set_msr_common(struct kvm_vcpu *
kvm_write_wall_clock(vcpu->kvm, data);
break;
case MSR_KVM_SYSTEM_TIME: {
+ if (vcpu->arch.time_page)
+ kvm_release_page_dirty(vcpu->arch.time_page);
+
vcpu->arch.time = data & PAGE_MASK;
vcpu->arch.time_offset = data & ~PAGE_MASK;
--
1.4.2
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/4] [PATCH] cacheline-align kvmclock structures
Align the kvm_vcpu_time array to the size of a cacheline.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/kvmclock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index b8da3bf..d82406a 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -36,7 +36,7 @@ early_param("no-kvmclock", parse_no_kvmc
struct shared_info shared_info __attribute__((__aligned__(PAGE_SIZE)));
/* The hypervisor will put information about time periodically here */
-static struct kvm_vcpu_time_info hv_clock[NR_CPUS];
+static struct kvm_vcpu_time_info hv_clock[NR_CPUS] __cacheline_aligned;
#define get_clock(cpu, field) hv_clock[cpu].field
static inline u64 kvm_get_delta(u64 last_tsc)
--
1.4.2
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/4] [PATCH] kvmclock: allow it to be turned off
Use the lower 3 lower bits of the system time msr to turn off the clock.
This means that all clock registration has to be aligned in a 4-byte boundary
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6abd784..7ce14ce 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -591,6 +591,11 @@ int kvm_set_msr_common(struct kvm_vcpu *
if (vcpu->arch.time_page)
kvm_release_page_dirty(vcpu->arch.time_page);
+ /* 4-byte unaligned accesses are invalid */
+ if (data & 0x7) {
+ vcpu->arch.time_page = NULL;
+ break;
+ }
vcpu->arch.time = data & PAGE_MASK;
vcpu->arch.time_offset = data & ~PAGE_MASK;
--
1.4.2
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 4/4] [PATCH] cleanup leftovers
clean this leftover in kvmclock.c
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/kvmclock.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index d82406a..8ff12b6 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -20,7 +20,6 @@ #include
#include
#include
#include
-#include
#define KVM_SCALE 22
@@ -33,8 +32,6 @@ static int parse_no_kvmclock(char *arg)
}
early_param("no-kvmclock", parse_no_kvmclock);
-struct shared_info shared_info __attribute__((__aligned__(PAGE_SIZE)));
-
/* The hypervisor will put information about time periodically here */
static struct kvm_vcpu_time_info hv_clock[NR_CPUS] __cacheline_aligned;
#define get_clock(cpu, field) hv_clock[cpu].field
--
1.4.2
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
Marcelo Tosatti wrote:
> On Wed, Mar 05, 2008 at 06:59:10PM +0200, Avi Kivity wrote:
>
>> Marcelo Tosatti wrote:
>>
>>> Handle the case where the balloon target is larger than total ram size.
>>>
>>> BUG: unable to handle kernel paging request at 00100100
>>> IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
>>>
>>> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>>>
>>> Index: virtio/virtio_balloon.c
>>> ===
>>> --- a/drivers/virtio/virtio_balloon.c
>>> +++ b/drivers/virtio/virtio_balloon.c
>>> @@ -122,10 +122,21 @@ static void release_pages_by_pfn(const u
>>> }
>>> }
>>>
>>> +static void update_target_size(struct virtio_balloon *vb)
>>> +{
>>> + __le32 num_pages = cpu_to_le32(vb->num_pages);
>>> +
>>> + vb->vdev->config->set(vb->vdev,
>>> + offsetof(struct virtio_balloon_config,
>>> num_pages),
>>> + &num_pages, sizeof(num_pages));
>>> +}
>>>
>>>
>> The target is host-owned; moreover the problem may be temporary, but
>> you've changed the target permanently.
>>
>> Suggest sending the host a message (like the page list) indicating it
>> couldn't allocate any more.
>>
>> Also, we may have driven the guest close to oom with this. We need to
>> notify the host when the guest gets into a low-memory cannot swap condition.
>>
>
> I guess the description was not clear, you understood the opposite.
>
> The problem is when the target for total guest pages (not balloon target
> size) is set to be larger than the amount of total pages the guest has
> booted with. What happens then is that the driver tries to release pages
> from the balloon, without checking if there are any:
>
target in the config space is target balloon size, not target for total
guest pages. So how is it ever possible for this condition to occur?
Regards,
Anthony Liguori
> static void leak_balloon(struct virtio_balloon *vb, size_t num)
> {
> struct page *page;
>
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
>
> for (vb->num_pfns = 0; vb->num_pfns < num; vb->num_pfns++) {
> page = list_first_entry(&vb->pages, struct page, lru);
> list_del(&page->lru);
> vb->pfns[vb->num_pfns] = page_to_pfn(page);
> vb->num_pages--;
> }
>
> vp->pages is empty here.
>
> So the patch checks for the availability of ballooned pages before
> attempting to release any, and sets num_pages to match that.
>
> The host should not allow that to condition to happen, but its still
> fragile code in the guest driver.
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] mmu notifiers #v8
On Wed, 5 Mar 2008, Nick Piggin wrote: > Um, it's bound to the *Linux page tables*, yes. And I have no idea why > you would use the paravirt ops for this. paravirt ops allows interception of page table operations? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-62 release
Alexey Eremenko wrote: > Very Nice. Must be KVM-63. > > >> - merge qemu-cvs >>- new curses display option >> > > How to activate that one? > > qemu -curses -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
> >I guess the description was not clear, you understood the opposite. > > > >The problem is when the target for total guest pages (not balloon target > >size) is set to be larger than the amount of total pages the guest has > >booted with. What happens then is that the driver tries to release pages > >from the balloon, without checking if there are any: > > > > target in the config space is target balloon size, not target for total > guest pages. So how is it ever possible for this condition to occur? Set the target in QEMU to be larger than guest ram size. The config space variable will be set negatively, so guest attempts to release pages from the balloon. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
Marcelo Tosatti wrote: >>> I guess the description was not clear, you understood the opposite. >>> >>> The problem is when the target for total guest pages (not balloon target >>> size) is set to be larger than the amount of total pages the guest has >>> booted with. What happens then is that the driver tries to release pages >>> >> >from the balloon, without checking if there are any: >> >>> >>> >> target in the config space is target balloon size, not target for total >> guest pages. So how is it ever possible for this condition to occur? >> > > Set the target in QEMU to be larger than guest ram size. The config > space variable will be set negatively, so guest attempts to release > pages from the balloon. > > Is an __le32 signed? If so, we should just use an unsigned type. Regards, Anthony Liguori - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/3] Expose thread id through info cpus
Hey, This patch series expose the actual thread id of each cpu via the qemu monitor. It is done through "info cpus", which I though would be the most natural command to do it. (If you disagree, please voice it) Goal is to allow tools like libvirt to easily grab it and feed taskset for thinks like cpu pinning, etc AFAIK, qemu runs all cpus in the same process, so for plain qemu, all cpus will show the same id. But KVM can benefit from it, by overriding this data in its ap initialization Of the whole series, only the last patch is kvm-specific. Many thanks to Anthony, who pointed me that this approach was possible. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] use a thread id variable
This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/cpu-defs.h |1 +
qemu/exec.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/qemu/cpu-defs.h b/qemu/cpu-defs.h
index 6979c11..6387a2f 100644
--- a/qemu/cpu-defs.h
+++ b/qemu/cpu-defs.h
@@ -162,6 +162,7 @@ typedef struct CPUTLBEntry {
\
void *next_cpu; /* next CPU sharing TB cache */ \
int cpu_index; /* CPU index (informative) */\
+int thread_id; \
/* user data */ \
void *opaque; \
\
diff --git a/qemu/exec.c b/qemu/exec.c
index 960adcd..b82d26d 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -340,6 +340,11 @@ void cpu_exec_init(CPUState *env)
}
env->cpu_index = cpu_index;
env->nb_watchpoints = 0;
+#ifdef __WIN32
+env->thread_id = GetCurrentProcessId();
+#else
+env->thread_id = getpid();
+#endif
*penv = env;
}
--
1.5.0.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] augment info cpus
This patch exposes the thread id associated with each
cpu through the already well known info cpus interface.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/monitor.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qemu/monitor.c b/qemu/monitor.c
index 0874671..4ee0b19 100644
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -335,6 +335,7 @@ static void do_info_cpus(void)
if (env->halted)
term_printf(" (halted)");
#endif
+term_printf(" thread_id=%d", env->thread_id);
term_printf("\n");
}
}
--
1.5.0.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM: use actual thread id for vcpus
At kvm ap creation, update CPUState with the actual thread id.
For us, they are actually different
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/qemu-kvm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 051946e..45fddd3 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -19,6 +19,7 @@ int kvm_irqchip = 1;
#include
#include
#include
+#include
extern void perror(const char *s);
@@ -49,6 +50,11 @@ struct vcpu_info {
int stopped;
} vcpu_info[256];
+static inline unsigned long kvm_get_thread_id(void)
+{
+return syscall(SYS_gettid);
+}
+
CPUState *qemu_kvm_cpu_env(int index)
{
return vcpu_info[index].env;
@@ -328,6 +334,7 @@ static void *ap_main_loop(void *_env)
vcpu = &vcpu_info[env->cpu_index];
vcpu->env = env;
+vcpu->env->thread_id = kvm_get_thread_id();
sigfillset(&signals);
//sigdelset(&signals, SIG_IPI);
sigprocmask(SIG_BLOCK, &signals, NULL);
@@ -374,6 +381,7 @@ int kvm_init_ap(void)
vcpu = &vcpu_info[0];
vcpu->env = first_cpu;
+vcpu->env->thread_id = kvm_get_thread_id();
signal(SIG_IPI, sig_ipi_handler);
for (i = 1; i < smp_cpus; ++i) {
kvm_init_new_ap(i, env);
--
1.5.0.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3] Expose thread id through info cpus
Oops! Forgot the -n option in git. Anyway, the series is small and straightforward, so I'm not reposting it. If there is any doubt about the ordering, please tell me. On Wed, Mar 5, 2008 at 5:01 PM, Glauber Costa <[EMAIL PROTECTED]> wrote: > Hey, > > This patch series expose the actual thread id of each cpu via the qemu > monitor. It is done through "info cpus", which I though would be the > most natural command to do it. (If you disagree, please voice it) > > Goal is to allow tools like libvirt to easily grab it and feed taskset > for thinks like cpu pinning, etc > > AFAIK, qemu runs all cpus in the same process, so for plain qemu, all cpus > will show the same id. But KVM can benefit from it, by overriding this data > in its ap initialization > > Of the whole series, only the last patch is kvm-specific. > > Many thanks to Anthony, who pointed me that this approach was possible. > > > -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
On Thursday 06 March 2008 03:28:32 Marcelo Tosatti wrote: > Handle the case where the balloon target is larger than total ram size. > > BUG: unable to handle kernel paging request at 00100100 > IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe > > Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> Hi Marcelo, My deepest concern is that we're papering over some real bug, if you tripped this. Zeroing num_pages makes sense as a hack, but we're clearly in trouble at this point and there should be some indication of that. If I may ask, how did this happen? Thanks, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote: > Anthony Liguori wrote: > > Playing a movie is a bit subjective. I presume you're talking about the > > standard HAL as presumably the ACPI HAL is using the pm timer? > > > > ACPI HAL uses the apic timer, IIRC; perhaps the pm timer as well. > > > So the two cases I'm hearing where timer accuracy should improve is > > standard HAL on Windows and clock=pit on Linux? I'd still like to see > > what the actual difference in timer accuracy is. > > It depends on the load. As the load increases, the host process starts > to miss timer signals. With both pic and pit in userspace, you can > detect those missed interrupts and inject them later once you get your > timeslice. With the pic in kernel, there is no way to do this. > > The same thing happens with the apic timer, only there, it is easy to > compensate because both parts are in the kernel. > > > I have no doubt that > > moving the pit into the kernel is more efficient. Moving everything > > into the kernel is more efficient because light weight exits are cheaper > > than heavy weight exits. > > > > Efficiency is only a secondary goal here. The userspace PIT does not > consume large amounts of CPU. > > > The thing I'm trying to get at is a quantitative statement about why > > moving the pit into the kernel is the right thing. I'll try to give the > > patches a try myself in the next couple of days. I don't think it's > > obvious that it's the right thing to do without some sort of benchmark > > supporting it. > > > > Playing a movie is better than any benchmark; it reflects actual user > experience in a real and important use case. Benchmarks are substitutes > for real use cases, not the goal of the optimization. > I forgot to mention that the benchmark is measuring time drift in the guest. Playing a movie in winxp changes the guest clock frequency from 100HZ to 1000HZ, thus causing a 250HZ host to coalesce pit irqs. So good pic & pit combination can handle guest multimedia without drifts while insufficient implementation just can't. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
Dor Laor wrote: > On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote: > >> >> Playing a movie is better than any benchmark; it reflects actual user >> experience in a real and important use case. Benchmarks are substitutes >> for real use cases, not the goal of the optimization. >> >> > > I forgot to mention that the benchmark is measuring time drift in the > guest. Playing a movie in winxp changes the guest clock frequency from > 100HZ to 1000HZ, thus causing a 250HZ host to coalesce pit irqs. > > So good pic & pit combination can handle guest multimedia without drifts > while insufficient implementation just can't. > I'll try out these patches in the next day or so. Is the expectation that Standard HAL + in-kernel APIC/PIT will have smoother playback than ACPI HAL w/o in-kernel APIC/PIT? I presume that the ACPI HAL is unaffected by in-kernel PIT? Regards, Anthony Liguori - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Lguest] networking in lguest: strange error: lguest: Guest moved used index from 6 to 256
On Wed, 2008-03-05 at 22:06 +1100, Rusty Russell wrote: > On Tuesday 04 March 2008 03:05:16 octane indice wrote: > > Hello > > > > I have some difficulty to use network inside lguest. > > I use a slackware 12 for guest and host with a 2.6.24 kernel. > > > > I boot lguest like that: > > # tunctl > > # ifconfig tap0 192.168.19.1 > > # lguest --tunnet=192.168.19.1 --block=/var/samba/iso/lguest.img 48 > > /usr/src/linux/arch/i386/boot/bzImage root=/dev/vda rw > > > > The init script files try to do a DHCP. It doesn't work (I do'nt have a > > DHCP server). > > > > If in the host I try to configure the eth0, lguest crashes strangely: > > [EMAIL PROTECTED]:~# ifconfig eth0 192.168.19.5 > > [EMAIL PROTECTED]:~# lguest: Guest moved used index from 6 to 256 > > Damn. This is fixed in Linus' tree, but I've reproduced it here for 2.6.24. > > It's non-trivial to repair, unfortunately (2.6.25 has a complete > reset > infrastructure for this). It will occur whenever the network device is > reopened, after packets were sent (or received). > > The workaround is to disable the dhcp in the init scripts... > You can also try to use backport scripts that automatically backport virtio to older guest kernels >= 2.6.18. It was written by Anthony Liguori and was decorated also by Avi and myself. Seems to work reliably with kvm, should do the same trick for lguest. You can download it from git://kvm.qumranet.com/home/dor/src/kvm-guest-drivers-linux Anthony, you can update your mercurial repository with our changes. Cheers, Dor > Thanks for the report, > Rusty. > ___ > Lguest mailing list > [EMAIL PROTECTED] > https://ozlabs.org/mailman/listinfo/lguest - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Lguest] networking in lguest: strange error: lguest: Guest moved used index from 6 to 256
Dor Laor wrote: > Seems to work reliably with kvm, should do the same trick for lguest. > You can download it from > git://kvm.qumranet.com/home/dor/src/kvm-guest-drivers-linux > > Anthony, you can update your mercurial repository with our changes. > Hrm, I thought we were standardizing on http://www.kernel.org/pub/scm/virt/kvm/kvm-guest-drivers-linux.git I'll just kill my mercurial repository. Regards, Anthony Liguori > Cheers, > Dor > > > >> Thanks for the report, >> Rusty. >> ___ >> Lguest mailing list >> [EMAIL PROTECTED] >> https://ozlabs.org/mailman/listinfo/lguest >> > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
On Wed, 2008-03-05 at 17:05 -0600, Anthony Liguori wrote: > Dor Laor wrote: > > On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote: > > > >> > >> Playing a movie is better than any benchmark; it reflects actual user > >> experience in a real and important use case. Benchmarks are substitutes > >> for real use cases, not the goal of the optimization. > >> > >> > > > > I forgot to mention that the benchmark is measuring time drift in the > > guest. Playing a movie in winxp changes the guest clock frequency from > > 100HZ to 1000HZ, thus causing a 250HZ host to coalesce pit irqs. > > > > So good pic & pit combination can handle guest multimedia without drifts > > while insufficient implementation just can't. > > > > I'll try out these patches in the next day or so. Is the expectation > that Standard HAL + in-kernel APIC/PIT will have smoother playback than > ACPI HAL w/o in-kernel APIC/PIT? I presume that the ACPI HAL is > unaffected by in-kernel PIT? > Standard HAL + userspace pic + -tdf option should give no guest time drift (actually sometimes massive correction of irq injection do the opposite, also since time drifts without -dtf it might look better but the movie does not runs in real time). Standard HAL + in-kernel pit patch + in-kernel irqchip should not drift. All other combinations should drift (sometimes you need to overload the cpu to see the drift). As for ACPI hal, the in-kernel apic doesn't drift, it also enable having flex priority or Avi's tpr optimization that boost overall performance. ACPI HAL should not be affected by the in-kernel pit. > Regards, > > Anthony Liguori > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Lguest] networking in lguest: strange error: lguest: Guest moved used index from 6 to 256
On Wed, 2008-03-05 at 17:10 -0600, Anthony Liguori wrote: > Dor Laor wrote: > > Seems to work reliably with kvm, should do the same trick for lguest. > > You can download it from > > git://kvm.qumranet.com/home/dor/src/kvm-guest-drivers-linux > > > > Anthony, you can update your mercurial repository with our changes. > > > > Hrm, I thought we were standardizing on > http://www.kernel.org/pub/scm/virt/kvm/kvm-guest-drivers-linux.git > Better this way, attached 3 patches needed for compilation. > I'll just kill my mercurial repository. > Regards, > > Anthony Liguori > > > Cheers, > > Dor > > > > > > > >> Thanks for the report, > >> Rusty. > >> ___ > >> Lguest mailing list > >> [EMAIL PROTECTED] > >> https://ozlabs.org/mailman/listinfo/lguest > >> > > > > > 0001-Backward-compat-to-replace-napi-in-rx_schedule.patch Description: application/mbox 0002-Move-COMPAT_csum_offset-to-kernels-.24-Also-add-e.patch Description: application/mbox 0003-Backport-skb_transport_header-as-a-BUG.-Since-kvm-h.patch Description: application/mbox - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Sharing a page of memory between the guest and host
Hello, Is it possible to share a memory (a page perhaps) between the host and guest? More precisely, could a host and guest share a memory-mapped file? If one were crazy enough to want to do this, where should they look first? Thanks, Cam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Notifier for Externally Mapped Memory (EMM) V1
This patch implements a simple callback for device drivers that establish
their own references to pages (KVM, GRU, XPmem, RDMA/Infiniband, DMA engines
etc). These references are unknown to the VM (therefore external).
With these callbacks it is possible for the device driver to release external
references when the VM requests it. This enables swapping, page migration and
allows support of remapping, permission changes etc etc for externally
mapped memory.
With this functionality it becomes also possible to avoid pinning or mlocking
pages (commonly done to stop the VM from unmapping device mapped pages).
A device driver must subscribe to a process using
emm_register_notifier(struct emm_notifier *, struct mm_struct *)
The VM will then perform callbacks for operations that unmap or change
permissions of pages in that address space. When the process terminates
the callback function is called with emm_release.
Callbacks are performed before and after the unmapping action of the VM.
emm_invalidate_startbefore
emm_invalidate_end after
The device driver must hold off establishing new references to pages
in the range specified between a callback with emm_invalidate_start and
the subsequent call with emm_invalidate_end set. This allows the VM to
ensure that no concurrent driver actions are performed on an address
range while performing remapping or unmapping operations.
Callbacks are mostly performed in a non atomic context. However, in
various places spinlocks are held to traverse rmaps. So this patch here
is only useful for those devices that can remove mappings in an atomic
context (f.e. KVM/GRU).
If the rmap spinlocks are converted to semaphores then all callbacks will
be performed in a nonatomic context. No additional changes will be necessary
to this patchset.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/mm_types.h |3 +
include/linux/rmap.h | 50 ++
kernel/fork.c|3 +
mm/Kconfig |5 +++
mm/filemap_xip.c |4 ++
mm/fremap.c |2 +
mm/hugetlb.c |3 +
mm/memory.c | 42 -
mm/mmap.c|3 +
mm/mprotect.c|3 +
mm/mremap.c |4 ++
mm/rmap.c| 78 +--
12 files changed, 190 insertions(+), 10 deletions(-)
Index: linux-2.6.25-rc3-mm1/include/linux/mm_types.h
===
--- linux-2.6.25-rc3-mm1.orig/include/linux/mm_types.h 2008-03-04
11:28:59.85232 -0800
+++ linux-2.6.25-rc3-mm1/include/linux/mm_types.h 2008-03-05
15:59:26.872868541 -0800
@@ -236,6 +236,9 @@ struct mm_struct {
struct file *exe_file;
unsigned long num_exe_file_vmas;
#endif
+#ifdef CONFIG_EMM_NOTIFIER
+ struct emm_notifier *emm_notifier;
+#endif
};
#endif /* _LINUX_MM_TYPES_H */
Index: linux-2.6.25-rc3-mm1/mm/Kconfig
===
--- linux-2.6.25-rc3-mm1.orig/mm/Kconfig2008-02-24 13:25:54.0
-0800
+++ linux-2.6.25-rc3-mm1/mm/Kconfig 2008-03-05 15:58:51.246302285 -0800
@@ -193,3 +193,8 @@ config NR_QUICK
config VIRT_TO_BUS
def_bool y
depends on !ARCH_NO_VIRT_TO_BUS
+
+config EMM_NOTIFIER
+ def_bool n
+ bool "External Mapped Memory Notifier for drivers directly mapping
memory"
+
Index: linux-2.6.25-rc3-mm1/include/linux/rmap.h
===
--- linux-2.6.25-rc3-mm1.orig/include/linux/rmap.h 2008-02-24
13:25:54.0 -0800
+++ linux-2.6.25-rc3-mm1/include/linux/rmap.h 2008-03-05 15:58:51.246302285
-0800
@@ -85,6 +85,56 @@ static inline void page_dup_rmap(struct
#endif
/*
+ * Notifier for devices establishing their own references to Linux
+ * kernel pages in addition to the regular mapping via page
+ * table and rmap. The notifier allows the device to drop the mapping
+ * when the VM removes references to pages.
+ */
+enum emm_operation {
+ emm_release,/* Process existing, */
+ emm_invalidate_start, /* Before the VM unmaps pages */
+ emm_invalidate_end, /* After the VM unmapped pages */
+ emm_referenced /* Check if a range was referenced */
+};
+
+struct emm_notifier {
+ int (*callback)(struct emm_notifier *e, struct mm_struct *mm,
+ enum emm_operation op,
+ unsigned long start, unsigned long end);
+ struct emm_notifier *next;
+};
+
+extern int __emm_notify(struct mm_struct *mm, enum emm_operation op,
+ unsigned long start, unsigned long end);
+
+/*
+ * Callback to the device driver for an externally memory mapped section
+ * of memory.
+ *
+ * start Address of first byte of the range
+ * end Address of first byte after range.
+ */
+stat
Re: [kvm-devel] Sharing a page of memory between the guest and host
Cam Macdonell wrote: > Hello, > > Is it possible to share a memory (a page perhaps) between the host and > guest? Yes, the host always has access to all of the guests memory. All of the virtio drivers depend on this fact. With KVM, the userspace (in this case, QEMU), just tells the kernel about a virtual address region and the kernel uses that region of virtual memory for the guest's physical memory. Whatever you (as userspace) maps into that region is totally up to you. > More precisely, could a host and guest share a memory-mapped > file? It will be a lot easier once we have MMU notifiers upstream. You'll be able to simply mmap(MAP_FIXED) a file into the guest's physical address space even while it's running. For now, you have to setup these mappings before the VM starts. > If one were crazy enough to want to do this, where should they > look first? > If you look at the -mem-file implementation in the latest git, you'll see that all the guest's memory can be an mmap()'d file. Regards, Anthony Liguori > Thanks, > Cam > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] mmu notifiers #v8
On Wed, Mar 05, 2008 at 10:48:24AM -0800, Christoph Lameter wrote: > On Wed, 5 Mar 2008, Nick Piggin wrote: > > > Um, it's bound to the *Linux page tables*, yes. And I have no idea why > > you would use the paravirt ops for this. > > paravirt ops allows interception of page table operations? Maybe possible but it's totally the wrong API for it. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] qemu: keep cpu_model as a constant string
Fixes :
qemu/hw/pc.c: In function `pc_init1':
qemu/hw/pc.c:1029: warning: passing arg 1 of `qemu_system_hot_add_init'
discards qualifiers from pointer target type
Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c |4 ++--
qemu/sysemu.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index e44c8b5..a85efe7 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -614,9 +614,9 @@ static void gpe_writeb(void *opaque, uint32_t addr,
uint32_t val)
#endif
}
-static char *model;
+static const char *model;
-void qemu_system_hot_add_init(char *cpu_model)
+void qemu_system_hot_add_init(const char *cpu_model)
{
register_ioport_write(GPE_BASE, 4, 1, gpe_writeb, &gpe);
register_ioport_read(GPE_BASE, 4, 1, gpe_readb, &gpe);
diff --git a/qemu/sysemu.h b/qemu/sysemu.h
index 73c57ab..9388fe4 100644
--- a/qemu/sysemu.h
+++ b/qemu/sysemu.h
@@ -154,7 +154,7 @@ extern int drive_get_max_bus(BlockInterfaceType type);
/* acpi */
void qemu_system_cpu_hot_add(int cpu, int state);
-void qemu_system_hot_add_init(char *cpu_model);
+void qemu_system_hot_add_init(const char *cpu_model);
/* vmchannel devices */
--
1.5.3.7
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 6/8] x86: KVM guest: hypercall batching
Hi Avi,
After reading the patch, I think the hypercall batching mechanism is as follows:
1 defer the MMU-related operations and buffer them in
kvm_para_state->mmu_queue[]
2 during the flush period, kvm_mmu_op() is called to flush operations
in kvm_para_state->mmu_queue[]
3 kvm_mmu_op() generate a hypercall for each operation in
kvm_para_state->mmu_queue[]; thus trigger a context switch from guest
mode to kernel mode for each operation.
My question is: Is it possible to only generate a single
hypercall(thus a single context switch) for all buffered MMU
operations in kvm_para_state->mmu_queue[]? This way we could further
reduce overhead, am I right?
BTW. I don't have a deep understanding of KVM. So this is just a
question out of my curiosity.
Thanks,
Forrest
On 3/3/08, Avi Kivity <[EMAIL PROTECTED]> wrote:
> From: Marcelo Tosatti <[EMAIL PROTECTED]>
>
> Batch pte updates and tlb flushes in lazy MMU mode.
>
> v1->v2:
> - report individual hypercall error code, have multicall return number of
> processed entries.
> - cover entire multicall duration with slots_lock instead of
> acquiring/reacquiring.
>
> v2->v3:
> - change to one ioctl per paravirt feature
>
> v3->v4:
> - adjust to mmu_op
> - helper for getting para_state without debug warnings
>
> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> ---
> arch/x86/kernel/kvm.c | 62
> +++-
> 1 files changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index e28d818..8405984 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -25,6 +25,22 @@
> #include
> #include
> #include
> +#include
> +
> +#define MMU_QUEUE_SIZE 1024
> +
> +struct kvm_para_state {
> + u8 mmu_queue[MMU_QUEUE_SIZE];
> + int mmu_queue_len;
> + enum paravirt_lazy_mode mode;
> +};
> +
> +static DEFINE_PER_CPU(struct kvm_para_state, para_state);
> +
> +static struct kvm_para_state *kvm_para_state(void)
> +{
> + return &per_cpu(para_state, raw_smp_processor_id());
> +}
>
> /*
> * No need for any "IO delay" on KVM
> @@ -47,6 +63,28 @@ static void kvm_mmu_op(void *buffer, unsigned len)
> } while (len);
> }
>
> +static void mmu_queue_flush(struct kvm_para_state *state)
> +{
> + if (state->mmu_queue_len) {
> + kvm_mmu_op(state->mmu_queue, state->mmu_queue_len);
> + state->mmu_queue_len = 0;
> + }
> +}
> +
> +static void kvm_deferred_mmu_op(void *buffer, int len)
> +{
> + struct kvm_para_state *state = kvm_para_state();
> +
> + if (state->mode != PARAVIRT_LAZY_MMU) {
> + kvm_mmu_op(buffer, len);
> + return;
> + }
> + if (state->mmu_queue_len + len > sizeof state->mmu_queue)
> + mmu_queue_flush(state);
> + memcpy(state->mmu_queue + state->mmu_queue_len, buffer, len);
> + state->mmu_queue_len += len;
> +}
> +
> static void kvm_mmu_write(void *dest, u64 val)
> {
> struct kvm_mmu_op_write_pte wpte = {
> @@ -55,7 +93,7 @@ static void kvm_mmu_write(void *dest, u64 val)
> .pte_val = val,
> };
>
> - kvm_mmu_op(&wpte, sizeof wpte);
> + kvm_deferred_mmu_op(&wpte, sizeof wpte);
> }
>
> /*
> @@ -122,7 +160,7 @@ static void kvm_flush_tlb(void)
> .header.op = KVM_MMU_OP_FLUSH_TLB,
> };
>
> - kvm_mmu_op(&ftlb, sizeof ftlb);
> + kvm_deferred_mmu_op(&ftlb, sizeof ftlb);
> }
>
> static void kvm_release_pt(u32 pfn)
> @@ -135,6 +173,23 @@ static void kvm_release_pt(u32 pfn)
> kvm_mmu_op(&rpt, sizeof rpt);
> }
>
> +static void kvm_enter_lazy_mmu(void)
> +{
> + struct kvm_para_state *state = kvm_para_state();
> +
> + paravirt_enter_lazy_mmu();
> + state->mode = paravirt_get_lazy_mode();
> +}
> +
> +static void kvm_leave_lazy_mmu(void)
> +{
> + struct kvm_para_state *state = kvm_para_state();
> +
> + mmu_queue_flush(state);
> + paravirt_leave_lazy(paravirt_get_lazy_mode());
> + state->mode = paravirt_get_lazy_mode();
> +}
> +
> static void paravirt_ops_setup(void)
> {
> pv_info.name = "KVM";
> @@ -160,6 +215,9 @@ static void paravirt_ops_setup(void)
> pv_mmu_ops.flush_tlb_user = kvm_flush_tlb;
> pv_mmu_ops.release_pt = kvm_release_pt;
> pv_mmu_ops.release_pd = kvm_release_pt;
> +
> + pv_mmu_ops.lazy_mode.enter = kvm_enter_lazy_mmu;
> + pv_mmu_ops.lazy_mode.leave = kvm_leave_lazy_mmu;
> }
> }
>
> --
> 1.5.4.2
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Re: [kvm-devel] Notifier for Externally Mapped Memory (EMM) V1
Christoph Lameter wrote:
>
> /*
> + * Notifier for devices establishing their own references to Linux
> + * kernel pages in addition to the regular mapping via page
> + * table and rmap. The notifier allows the device to drop the mapping
> + * when the VM removes references to pages.
> + */
> +enum emm_operation {
> + emm_release,/* Process existing, */
> + emm_invalidate_start, /* Before the VM unmaps pages */
> + emm_invalidate_end, /* After the VM unmapped pages */
> + emm_referenced /* Check if a range was referenced */
> +};
>
Check and clear
btw, a similar test and clear dirty would be useful as well, no?
> +
> +struct emm_notifier {
> + int (*callback)(struct emm_notifier *e, struct mm_struct *mm,
> + enum emm_operation op,
> + unsigned long start, unsigned long end);
> + struct emm_notifier *next;
> +};
> +
>
It is cleaner for the user to specify individual callbacks instead of
having a switch.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/4] [PATCH] kvmclock: release time_page if msr is rewritten
Glauber Costa wrote: > If the calling cpu rewrites the system clock msr for any reason, > release the page we allocated in the last time > Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/4] [PATCH] cacheline-align kvmclock structures
Glauber Costa wrote:
> Align the kvm_vcpu_time array to the size of a cacheline.
>
> Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
> ---
> arch/x86/kernel/kvmclock.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> index b8da3bf..d82406a 100644
> --- a/arch/x86/kernel/kvmclock.c
> +++ b/arch/x86/kernel/kvmclock.c
> @@ -36,7 +36,7 @@ early_param("no-kvmclock", parse_no_kvmc
> struct shared_info shared_info __attribute__((__aligned__(PAGE_SIZE)));
>
> /* The hypervisor will put information about time periodically here */
> -static struct kvm_vcpu_time_info hv_clock[NR_CPUS];
> +static struct kvm_vcpu_time_info hv_clock[NR_CPUS] __cacheline_aligned;
> #define get_clock(cpu, field) hv_clock[cpu].field
>
> static inline u64 kvm_get_delta(u64 last_tsc)
>
I think this will align only the array itself, not members, so any write
will (and the following reads) will cause a cacheline bounce.
Switching to per_cpu() both clarifies the intent and fixes the issue.
Still need the 8-byte alignment. Might be best to stick that on the
structure declaration, so it applies to all guests.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/4] [PATCH] kvmclock: allow it to be turned off
Glauber Costa wrote:
> Use the lower 3 lower bits of the system time msr to turn off the clock.
> This means that all clock registration has to be aligned in a 4-byte boundary
>
>
3 bits -> 8 bytes.
How about just using just bit 0 as an enable bit (not a disable bit).
That means the default value of zero means the clock is disabled, and
that we have a couple of more bits to enable future features.
> Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
> ---
> arch/x86/kvm/x86.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 6abd784..7ce14ce 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -591,6 +591,11 @@ int kvm_set_msr_common(struct kvm_vcpu *
> if (vcpu->arch.time_page)
> kvm_release_page_dirty(vcpu->arch.time_page);
>
> + /* 4-byte unaligned accesses are invalid */
> + if (data & 0x7) {
> + vcpu->arch.time_page = NULL;
> + break;
> + }
> vcpu->arch.time = data & PAGE_MASK;
> vcpu->arch.time_offset = data & ~PAGE_MASK;
>
>
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/4] [PATCH] cleanup leftovers
Glauber Costa wrote: > clean this leftover in kvmclock.c > > Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3] Expose thread id through info cpus
Glauber Costa wrote: > Hey, > > This patch series expose the actual thread id of each cpu via the qemu > monitor. It is done through "info cpus", which I though would be the > most natural command to do it. (If you disagree, please voice it) > > Goal is to allow tools like libvirt to easily grab it and feed taskset > for thinks like cpu pinning, etc > > AFAIK, qemu runs all cpus in the same process, so for plain qemu, all cpus > will show the same id. But KVM can benefit from it, by overriding this data > in its ap initialization > > Of the whole series, only the last patch is kvm-specific. > > Many thanks to Anthony, who pointed me that this approach was possible. > > > Applied all, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-balloon: do not attempt to release more than available pages
Anthony Liguori wrote: >> >> Set the target in QEMU to be larger than guest ram size. The config >> space variable will be set negatively, so guest attempts to release >> pages from the balloon. >> >> >> > > Is an __le32 signed? If so, we should just use an unsigned type. > > That would balloon the guest into oblivion if the same condition happened. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 6/8] x86: KVM guest: hypercall batching
Zhao Forrest wrote: > Hi Avi, > > After reading the patch, I think the hypercall batching mechanism is as > follows: > 1 defer the MMU-related operations and buffer them in > kvm_para_state->mmu_queue[] > 2 during the flush period, kvm_mmu_op() is called to flush operations > in kvm_para_state->mmu_queue[] > 3 kvm_mmu_op() generate a hypercall for each operation in > kvm_para_state->mmu_queue[]; thus trigger a context switch from guest > mode to kernel mode for each operation. > > My question is: Is it possible to only generate a single > hypercall(thus a single context switch) for all buffered MMU > operations in kvm_para_state->mmu_queue[]? This way we could further > reduce overhead, am I right? > BTW. I don't have a deep understanding of KVM. So this is just a > question out of my curiosity. > > mmu_queue_flush() is called once per batch, so we only have one hypercall per batch (at least if the data doesn't exceed 512 bytes). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
