Re: [kvm-devel] [PATCH 1/3] [PATCH] passthrough
Glauber Costa wrote: > add -passthrough usage string > > Signed-off-by: Glauber Costa <[EMAIL PROTECTED]> > --- > qemu/vl.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/qemu/vl.c b/qemu/vl.c > index f5b2665..d36cfe3 100644 > --- a/qemu/vl.c > +++ b/qemu/vl.c > @@ -8053,6 +8053,7 @@ #ifdef USE_KVM > #ifndef NO_CPU_EMULATION > "-no-kvm disable KVM hardware virtualization\n" > #endif > +"-passthrough name/bus:dev.func-intr expose a pci device to the > guest OS \n" > "-no-kvm-irqchip disable KVM kernel mode PIC/IOAPIC/LAPIC\n" > #endif > #ifdef TARGET_I386 > Not this patch's fault, of course, but it would be better to name the option -pcidevice, to be consistent with -usbdevice, and to show only pci devices are allowed. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] [PATCH] unregister pci device
Glauber Costa wrote: > If we fail after we have allocated the pci device, we have > to get rid of it. Otherwise, a bogus device will be found on > the bus > Maybe, alter the order so the device is registered last thing. This may help avoid races with pci passthrough hotplug. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote: > Any tlb flush happening before clearing the shadow-pte entry is > totally useless. > > Doh! Well that's easy to fix, by moving the spte clear to rmap_remove(). -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote:
> On Wed, Mar 26, 2008 at 08:22:31PM +0100, Andrea Arcangeli wrote:
>
>> what happens if invalidate_page runs after rmap_remove is returned
>> (the spte isn't visible anymore by the rmap code and in turn by
>> invalidate_page) but before the set_shadow_pte(nonpresent) runs.
>>
>
> Thinking some more the mmu_lock is meant to prevent this. So
> invalidate_page should wait. As long as the kvm tlb flush happens
> inside the mmu lock we should be safe.
>
> Fixing it with mmu notifiers is the higher performance way too. This
> would be the patch if we decide to do that.
>
>
Well, obviously mmu notifiers is the future and we should code for that,
instead of increasing code complexity.
> Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 95c12bc..80cf172 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -550,6 +550,7 @@ static void rmap_remove(struct kvm *kvm, u64 *spte)
> sp = page_header(__pa(spte));
> page = spte_to_page(*spte);
> mark_page_accessed(page);
> + BUG_ON(page_count(page) <= 1);
> if (is_writeble_pte(*spte))
> kvm_release_page_dirty(page);
> else
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 30bf832..a49987c 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -741,6 +741,10 @@ static struct vm_operations_struct kvm_vcpu_vm_ops = {
> static int kvm_vcpu_mmap(struct file *file, struct vm_area_struct *vma)
> {
> vma->vm_ops = &kvm_vcpu_vm_ops;
> +#ifndef CONFIG_MMU_NOTIFIER
> + /* prevent the VM to release pages under sptes mappings */
> + vma->vm_flags |= VM_LOCKED;
> +#endif
> return 0;
> }
>
>
That's sad, but I guess the only safe and simple option is to queue this
for 2.6.25 and remove it in 2.6.26.
--
error compiling committee.c: too many arguments to function
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] ignore reads to the EOI register.
Glauber Costa wrote: > They seem legal in real hardware, even though the EOI > is a write-only register. By "legal" I mean they are completely > ignored, but at least, don't cause any bits to be set at ESR. > > Without this patch, some (very recent) linux git trees will fail > to boot in i386. > > This is generated from kvm-userspace, but should apply well to > plain qemu too. > > Applied, but perhaps a patch to linux to avoid reads to write-only registers is needed as well. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH v2] x86: don't allow KVM_CLOCK on Voyager or Visual WS
Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > Prevent failed randconfig builds with KVM_CLOCK being enabled > on Voyager or VISWS. > > Applies, thanks. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM Test result, kernel c0af88e.., userspace 0342df6..
Hi Alll, This is today's KVM test result against kvm.git c0af88e9014019f6392b06c11e836ca58acc7ede and kvm-userspace.git 0342df67ec22f3d9aa663949b72694e061c2edb2. Issue list 1. Booting four guests likely fails https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1919354&group_id=180599 2. booting smp windows guests has 30% chance of hang https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1910923&group_id=180599 3. slab error in kmem_cache_destroy(): cache `kvm_vcpu': https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1925889&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 FAIL 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 32. reboot 32bit windows xp guestPASS 33. reboot 32bit windows xp guest PASS Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 7 7 0 00 Restart 2 2 0 00 gtest 15 15 0 00 ===
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 30bf832..a49987c 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -741,6 +741,10 @@ static struct vm_operations_struct kvm_vcpu_vm_ops = {
> static int kvm_vcpu_mmap(struct file *file, struct vm_area_struct *vma)
> {
> vma->vm_ops = &kvm_vcpu_vm_ops;
> +#ifndef CONFIG_MMU_NOTIFIER
> + /* prevent the VM to release pages under sptes mappings */
> + vma->vm_flags |= VM_LOCKED;
> +#endif
> return 0;
> }
>
>
Erm I don't think this means what you think it means. This is the
kernel/user communication area, used to pass exit data to userspace.
It's not the memslot vma.
--
error compiling committee.c: too many arguments to function
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Dave Hansen wrote: > On Wed, 2008-03-26 at 18:58 +0200, Avi Kivity wrote: > >> Dave Hansen wrote: >> >>> On Wed, 2008-03-26 at 11:50 +0200, Avi Kivity wrote: >>> Dave Hansen wrote: > I was getting some kvm userspace crashes trying to run a Windows guest. > So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with > the kvm kernel code that shipped with that kernel. > > > This is fixed in 2.6.25-rc7. >>> I just updated to -rc7 and re-tested. Same symptoms: >>> >> Bad. Which kvm userspace are you running? >> > > ~/src/kvm-userspace$ git describe > kvm-63-118-g52be1a1 > > I dug out my i386 install and tried it. Doesn't reproduce for me on either kvm.git or -rc7. Do you have a working setup that we can bisect? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/20] dma_ops for i386
* On Wednesday 26 March 2008 03:06:19 Glauber Costa wrote: > Hello, > > Here there is a series of 20 patches that lays the foundations for > using dma_ops in i386 in the very same way x86_64, as well as many other > architectures already do. Thanks; Please also see Stephen Tweedie's tree at http://git.et.redhat.com/?p=linux-2.6-dom0-pvops.git;a=summary I guess your work would be overlapped anyway, but just to make sure there's no double work. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Avi Kivity wrote: > Dave Hansen wrote: >> On Wed, 2008-03-26 at 18:58 +0200, Avi Kivity wrote: >> >>> Dave Hansen wrote: >>> On Wed, 2008-03-26 at 11:50 +0200, Avi Kivity wrote: > Dave Hansen wrote: > >> I was getting some kvm userspace crashes trying to run a Windows >> guest. >> So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) >> with >> the kvm kernel code that shipped with that kernel. > [...] btw, is this with >= 4GB RAM on the host? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel c0af88e.., userspace 0342df6..
Yunfeng Zhao wrote: > Hi Alll, > > This is today's KVM test result against kvm.git > c0af88e9014019f6392b06c11e836ca58acc7ede and kvm-userspace.git > 0342df67ec22f3d9aa663949b72694e061c2edb2. > > > 3. slab error in kmem_cache_destroy(): cache `kvm_vcpu': > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1925889&group_id=180599 > > This should have been fixed by the commits mentioned. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtual machines network goes 100Mbit when interface is Gbit
Hello, I'm not sure if I understand you. Do you mean that the physical network cards should be e1000 or that the virtual machines must somehow emulate e1000 network cards? As I understand Miguel's post, he is finding an issue with the bridge's speed (two virtual machines running on the same physical machine are limited to 100 Mbps between themselves). Best regards, Víctor Haydn Solomon escribió: > What emulated nic are you using? I think only the e1000 emulated nic > supports 1 GB. > > Miguel Araujo wrote: > >> Hello all, >> >> I'm testing the last kvm version, 62. I was doing an iperf benchmark to >> test the network performance in a Feisty virtual machine and I got >> values surround 100Mbits when my card is actually 1Gbit. The testing >> environment is conformed by 2 machines, both with Gbit interfaces. The >> vm in kvm is running in server mode, the other (not virtualized one) is >> the client. The vm interface is going to a bridge called br0. Ethtool >> says the interface is running 100Mbits but it doesn't let me change the >> speed or any other parameter in the vm. >> >> I can't either change tap0 parameters in kvm host. ¿Is anyone having the >> same issue?¿am I forgetting something? >> >> Thanks for your time in advanced, >> Miguel >> >> - >> 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 > -- Víctor Abeytua García --- Socio Consultor Nosys AJjV S.L. Networked Open SYStems Tecnologías de la Información - Seguridad C/ Isla Graciosa 2, Loft 18 28700 San Sebastián de los Reyes Madrid (Spain) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 15/20] x86: move dma_supported and dma_set_mask to pci-dma_32.c
On Tue, 2008-03-25 at 18:36 -0300, Glauber Costa wrote:
> This is the way x86_64 does, so this make them equal. They have
> to be extern now in the header, and the extern definition is moved to
> the common dma-mapping.h header
>
> Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
...
> diff --git a/arch/x86/kernel/pci-dma_32.c b/arch/x86/kernel/pci-dma_32.c
> index 5133032..453b4bd 100644
> --- a/arch/x86/kernel/pci-dma_32.c
> +++ b/arch/x86/kernel/pci-dma_32.c
> @@ -156,6 +156,39 @@ EXPORT_SYMBOL(dma_mark_declared_memory_occupied);
> int forbid_dac;
> EXPORT_SYMBOL(forbid_dac);
>
> +int
> +dma_supported(struct device *dev, u64 mask)
> +{
...
> +}
> +
> +int
> +dma_set_mask(struct device *dev, u64 mask)
> +{
...
> +}
...
> diff --git a/include/asm-x86/dma-mapping_32.h
> b/include/asm-x86/dma-mapping_32.h
> index e60c30a..fd7246d 100644
> --- a/include/asm-x86/dma-mapping_32.h
> +++ b/include/asm-x86/dma-mapping_32.h
> @@ -17,35 +17,6 @@ dma_mapping_error(dma_addr_t dma_addr)
> extern int forbid_dac;
>
> static inline int
> -dma_supported(struct device *dev, u64 mask)
> -{
...
> -}
> -
> -static inline int
> -dma_set_mask(struct device *dev, u64 mask)
> -{
...
> -}
This breaks for me with:
ERROR: "dma_supported" [drivers/ssb/ssb.ko] undefined!
ERROR: "dma_set_mask" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined!
ERROR: "dma_set_mask" [drivers/scsi/aic7xxx/aic7xxx.ko] undefined!
ERROR: "dma_set_mask" [drivers/scsi/aic7xxx/aic79xx.ko] undefined!
ERROR: "dma_supported" [drivers/net/pcnet32.ko] undefined!
ERROR: "dma_supported" [drivers/media/video/saa7134/saa7134.ko] undefined!
ERROR: "dma_set_mask" [drivers/media/video/meye.ko] undefined!
ERROR: "dma_supported" [drivers/media/video/cx88/cx8802.ko] undefined!
ERROR: "dma_supported" [drivers/media/video/cx88/cx8800.ko] undefined!
ERROR: "dma_supported" [drivers/media/video/cx88/cx88-alsa.ko] undefined!
ERROR: "dma_supported" [drivers/media/video/cx23885/cx23885.ko] undefined!
They just need to be exported like on x86_64.
Cheers,
Mark.
Subject: [PATCH] x86: export dma_supported() and dma_set_mask() on i386
dma_supported() and dma_set_mask() were previously inlined,
but are now moved to pci-dma_32.c.
Since they're used by various drivers, they need to be
exported.
Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
---
arch/x86/kernel/pci-dma_32.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/pci-dma_32.c b/arch/x86/kernel/pci-dma_32.c
index 55ab3c8..be6b1f6 100644
--- a/arch/x86/kernel/pci-dma_32.c
+++ b/arch/x86/kernel/pci-dma_32.c
@@ -180,6 +180,7 @@ dma_supported(struct device *dev, u64 mask)
return 1;
}
+EXPORT_SYMBOL(dma_supported);
int
dma_set_mask(struct device *dev, u64 mask)
@@ -191,6 +192,7 @@ dma_set_mask(struct device *dev, u64 mask)
return 0;
}
+EXPORT_SYMBOL(dma_set_mask);
static __devinit void via_no_dac(struct pci_dev *dev)
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] ignore reads to the EOI register.
On Thu, 27 Mar 2008, Avi Kivity wrote: > Applied, but perhaps a patch to linux to avoid reads to write-only registers > is needed as well. Linux performs reads to all registers written including this one deliberately using an RMW cycle to avoid triggering an erratum in some early Pentium integrated APICs. Obviously it does not matter for most of the world as the workaround is build-time conditional, but you'll get it if you build a generic "runs everywhere" kernel. Maciej - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] [PATCH] unregister pci device
Avi Kivity wrote: > Glauber Costa wrote: >> If we fail after we have allocated the pci device, we have >> to get rid of it. Otherwise, a bogus device will be found on >> the bus >> > > Maybe, alter the order so the device is registered last thing. This may > help avoid races with pci passthrough hotplug. > That's the first thing I thought, but it makes things much more complicated. If really deserved, I can try again. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] [PATCH] unregister pci device
Glauber Costa wrote: > Avi Kivity wrote: >> Glauber Costa wrote: >>> If we fail after we have allocated the pci device, we have >>> to get rid of it. Otherwise, a bogus device will be found on >>> the bus >>> >> >> Maybe, alter the order so the device is registered last thing. This >> may help avoid races with pci passthrough hotplug. >> > That's the first thing I thought, but it makes things much more > complicated. If really deserved, I can try again. I don't think it's that critical at this stage. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 15/20] x86: move dma_supported and dma_set_mask to pci-dma_32.c
* Mark McLoughlin <[EMAIL PROTECTED]> wrote: > This breaks for me with: > > ERROR: "dma_supported" [drivers/ssb/ssb.ko] undefined! > ERROR: "dma_set_mask" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! > ERROR: "dma_set_mask" [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! > ERROR: "dma_set_mask" [drivers/scsi/aic7xxx/aic79xx.ko] undefined! > ERROR: "dma_supported" [drivers/net/pcnet32.ko] undefined! > ERROR: "dma_supported" [drivers/media/video/saa7134/saa7134.ko] undefined! > ERROR: "dma_set_mask" [drivers/media/video/meye.ko] undefined! > ERROR: "dma_supported" [drivers/media/video/cx88/cx8802.ko] undefined! > ERROR: "dma_supported" [drivers/media/video/cx88/cx8800.ko] undefined! > ERROR: "dma_supported" [drivers/media/video/cx88/cx88-alsa.ko] undefined! > ERROR: "dma_supported" [drivers/media/video/cx23885/cx23885.ko] undefined! > > They just need to be exported like on x86_64. thanks Mark, applied. Ingo - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC/PATCH 00/15 v3] kvm on big iron
Carsten Otte wrote: > Many thanks for the review feedback we have received so far, > and many thanks to Andrew for reviewing our common code memory > management changes. I do greatly appreciate that :-). > > All important parts have been reviewed, all review feedback has been > integrated in the code. Therefore we would like to ask for inclusion of > our work into kvm.git. > > Changes from Version 1: > - include feedback from Randy Dunlap on the documentation > - include feedback from Jeremy Fitzhardinge, the prototype for dup_mm > has moved to include/linux/sched.h > - rebase to current kvm.git hash g361be34. Thank you Avi for pulling > in the fix we need, and for moving KVM_MAX_VCPUS to include/arch :-). > > Changes from Version 2: > - include feedback from Rusty Russell on the virtio patch > - include fix for race s390_enable_sie() versus ptrace spotted by Dave > Hansen: we now do task_lock() to protect mm_users from update while > we're growing the page table. Good catch, Dave :-). > - rebase to current kvm.git hash g680615e > > Applied all, thanks. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] crash booting Windows with current -git
I'm getting the following crash with current -git userspace. I'm running a stock 2.6.22-14-generic ubuntu kernels with modules from the kvm-userspace tree. I believe my BIOS images are also from current -git. The crash occurs about 10 or 15 seconds after the GUI comes up. Booting with -no-kvm is OK. [EMAIL PROTECTED]:~/projects/qemu$ ~/src/kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda ~/projects/qemu/windows-xp-base-runme.img qemu: unsupported keyboard cmd=0xa1 qemu: unsupported keyboard cmd=0xba unhandled vm exit: 0x9 vcpu_id 0 rax fc65b948 rbx 806ed0e0 rcx rdx rsi 811f84d8 rdi 806ed0b8 rsp 15fffc5f rbp fc65b96c r8 r9 r10 r11 r12 r13 r14 r15 rip fc5f157e rflags 00010206 cs 0008 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) ds 0023 (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) es 0023 (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0030 (ffdff000/1fff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0028 (80042000/20ab p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 8003f000/3ff idt 8003f400/7ff cr0 8001003b cr2 806ed0b4 cr3 3b8f000 cr4 6d8 cr8 0 efer 0 Aborted (core dumped) -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] manage number of VCPU and memory
Thanks, it worked... But I have one more question, is there also some command for changing actual memory like cpu_set for setting number of VCPUs? Thanks in advance b. __ > Od: [EMAIL PROTECTED] > Komu: bĹeĹĽa <[EMAIL PROTECTED]> > CC: kvm-devel@lists.sourceforge.net > Datum: 19.03.2008 13:26 > Předmět: Re: [kvm-devel] manage number of VCPU and memory > >břeťa wrote: >> Hi, >> I want to ask for a help in searching specific documetation. > I am looking for any information about how to change the number of VCPU and amount of memory while the VM is running (or at least the magic keywords for google; I was successful in searching information about how to do that in Xen but not in the KVM). >> Thanks in advance for any advices or links. >> >There is the cpu_set command in the qemu monitor. > > >-- error compiling committee.c: too many arguments to function > > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM: register the kvm mmu cache with the shrinker.
Izik Eidus wrote:
> void kvm_mmu_module_exit(void)
> {
> if (pte_chain_cache)
> @@ -1980,6 +2026,7 @@ void kvm_mmu_module_exit(void)
> kmem_cache_destroy(rmap_desc_cache);
> if (mmu_page_header_cache)
> kmem_cache_destroy(mmu_page_header_cache);
> + unregister_shrinker(&mmu_shrinker);
> }
>
kvm_mmu_module_exit() can be called from the nomem: label below, so the
shrinker will be unregistered despite not being registered.
Suggest renaming kvm_mmu_module_exit() to mmu_destroy_caches(), and
adding a new kvm_mmu_module_exit() which will call mmu_destroy_caches()
and unregister_shrinker().
>
> int kvm_mmu_module_init(void)
> @@ -2001,6 +2048,8 @@ int kvm_mmu_module_init(void)
> if (!mmu_page_header_cache)
> goto nomem;
>
> + register_shrinker(&mmu_shrinker);
> +
> return 0;
>
> nomem:
>
--
error compiling committee.c: too many arguments to function
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] ignore reads to the EOI register.
Andi Kleen wrote: > "Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: > >> Linux performs reads to all registers written including this one >> deliberately using an RMW cycle to avoid triggering an erratum in some >> early Pentium integrated APICs. Obviously it does not matter for most of >> the world as the workaround is build-time conditional, but you'll get it >> if you build a generic "runs everywhere" kernel. >> > > It would be quite possible to make the cycle conditional on a > cpufeatures.h quirk flag that is only set on P5. Just would need to > out of line a few functions to avoid code bloat. > Or, alternatives? xchg vs mov? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] crash booting Windows with current -git
On Tue, 2008-03-25 at 12:38 -0700, Dave Hansen wrote: > I'm getting the following crash with current -git userspace. I'm > running a stock 2.6.22-14-generic ubuntu kernels with modules from the > kvm-userspace tree. I believe my BIOS images are also from current > -git. I didn't understand if the kvm modules are from the stock kernel or synced against kvm kernel git tree? > > The crash occurs about 10 or 15 seconds after the GUI comes up. > > Booting with -no-kvm is OK. > > [EMAIL PROTECTED]:~/projects/qemu$ > ~/src/kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda > ~/projects/qemu/windows-xp-base-runme.img Just for safety please add '-L ~/src/kvm-userspace/qemu/pc-bios > qemu: unsupported keyboard cmd=0xa1 > qemu: unsupported keyboard cmd=0xba > unhandled vm exit: 0x9 vcpu_id 0 > rax fc65b948 rbx 806ed0e0 rcx rdx > > rsi 811f84d8 rdi 806ed0b8 rsp 15fffc5f rbp > fc65b96c > r8 r9 r10 r11 > > r12 r13 r14 r15 > > rip fc5f157e rflags 00010206 > cs 0008 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) > ds 0023 (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) > es 0023 (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) > ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > fs 0030 (ffdff000/1fff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) > tr 0028 (80042000/20ab p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) > gdt 8003f000/3ff > idt 8003f400/7ff > cr0 8001003b cr2 806ed0b4 cr3 3b8f000 cr4 6d8 cr8 0 efer 0 > Aborted (core dumped) > > -- Dave > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] ignore reads to the EOI register.
On Thu, 27 Mar 2008, Andi Kleen wrote: > It would be quite possible to make the cycle conditional on a > cpufeatures.h quirk flag that is only set on P5. Just would need to > out of line a few functions to avoid code bloat. Exactly what I suggested at the LKML -- you could even go down to a list of steppings affected as an RMW cycle is unnecessarily expensive (we only need interrupt atomicity, but there is no way to disable the LOCK# implication of "xchg"). Maciej - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
On Thu, Mar 27, 2008 at 10:11:42AM +0200, Avi Kivity wrote: > Erm I don't think this means what you think it means. This is the > kernel/user communication area, used to pass exit data to userspace. It's > not the memslot vma. Yep... only the kvm_vm_vm_ops can run gfn_to_page, and I assume that was used by the old userland and not relevant anymore (smaps don't show it either), or the pages could not be unmapped. So btw, that kvm-vm anon inode must be disabled when mmu notifiers are configured in to guarantee that access to /dev/kvm won't lead to mlock behavior. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] manage number of VCPU and memory
Břeťa Vomočil wrote: > Thanks, it worked... > But I have one more question, is there also some command for changing actual > memory like cpu_set for setting number of VCPUs? > > There's the balloon driver, but that is not yet merged. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote: > On Thu, Mar 27, 2008 at 10:11:42AM +0200, Avi Kivity wrote: > >> Erm I don't think this means what you think it means. This is the >> kernel/user communication area, used to pass exit data to userspace. It's >> not the memslot vma. >> > > Yep... only the kvm_vm_vm_ops can run gfn_to_page, and I assume that > was used by the old userland and not relevant anymore (smaps don't > show it either), or the pages could not be unmapped. So btw, that > kvm-vm anon inode must be disabled when mmu notifiers are configured > in to guarantee that access to /dev/kvm won't lead to mlock behavior. > That's not good. We need to support the older userspace, for a while yet. Why is there a problem? IIRC it's just anonymous memory. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
On Thu, Mar 27, 2008 at 03:56:56PM +0200, Avi Kivity wrote: > That's not good. We need to support the older userspace, for a while yet. > > Why is there a problem? IIRC it's just anonymous memory. Problem is that for it to be unmapped __do_fault must call page_add_new_anon_rmap on it. Even anon would be 1, that would mean cow and that's clearly not what you want as it would lose the visibility on the future guest writes. anon will be 0 if qemu is reading for example, leaving pinned anonymous memory that mmu notifiers won't be able to swap anymore. This is about providing the guarantee to the admin, that if he enables the mmu notifiers in the kernel, giving access to /dev/kvm won't give full mlock privileges too. Not sure if anybody will care, but it's a bit like removing the limit on tmpfs that only half ram can be pinned. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-64 release
Major changes: PCI hotplug; improved PIT accuracy; paravirt mmu. Changes from kvm-63: - kvm clock fixes (Glauber Costa) - kvm clock enable/disable bit (Glauber Costa) - in kernel pit model (Sheng Yang) - improves timing accuracy for certain guests - fix bad tss handling causing ioperm() to fail on the host - paravirt mmu support (Marcelo Tosatti, Anthony Liguori, me) - set accessed bit on non-speculative shadow ptes - minor performance improvement - fix init_rmode_tss() locking (Marcelo Tosatti) - fix dirty bit being lost when write permissions are removed from a page (Izik Eidus) - code cleanups - module option for disabling flexpriority - fix apic access page memory leak - hardware task switching support (Izik Eidus) - for freedos and similar guests - fix extboot failures under certain conditions (Anthony Liguori) - export vcpu thread ID via qemu monitor (Glauber Costa) - can be used to implement vcpu->cpu pinning - pci hotplug (Marcelo Tosatti) - can now add and remove nics and drives dynamically - fix virtio memory region sizing (Marcelo Tosatti) - fix segfault on disabled virtio nic (Dor Laor) - fix sci interrupt on pmtimer wraparound (Dor Laor, Yaniv Kamay) - fix qemu exit on pci hotplug failure (Ryan Harper) - fix 'make clean' destroying configuration (Ryota OZAKI) - ppc userspace updates (Jerone Young) - improve IDE and SCSI DMA speed Notes: If you use the modules bundled with kvm-64, 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 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote: > On Thu, Mar 27, 2008 at 03:56:56PM +0200, Avi Kivity wrote: > >> That's not good. We need to support the older userspace, for a while yet. >> >> Why is there a problem? IIRC it's just anonymous memory. >> > > Problem is that for it to be unmapped __do_fault must call > page_add_new_anon_rmap on it. Even anon would be 1, that would mean > cow and that's clearly not what you want as it would lose the > visibility on the future guest writes. anon will be 0 if qemu is > reading for example, leaving pinned anonymous memory that mmu > notifiers won't be able to swap anymore. This is about providing the > guarantee to the admin, that if he enables the mmu notifiers in the > kernel, giving access to /dev/kvm won't give full mlock privileges > too. Not sure if anybody will care, but it's a bit like removing the > limit on tmpfs that only half ram can be pinned. > We can put it under a Kconfig option. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
On Thu, Mar 27, 2008 at 04:35:55PM +0200, Avi Kivity wrote: > We can put it under a Kconfig option. Yes, I thought the MMU_NOTIFIER knob would be enough but we can of course add more finegrined options if we think it worth to allow unprivileged users to own /dev/kvm. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Thu, 2008-03-27 at 12:10 +0200, Avi Kivity wrote: > btw, is this with >= 4GB RAM on the host? Well, are you asking whether I have PAE on or not? :) The host has 4GB of RAM exactly, but there are some serious BIOS holes, so I needed PAE because about a gig of it is mapped >4GB. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009d800 (usable) [0.00] BIOS-e820: 0009d800 - 000a (reserved) [0.00] BIOS-e820: 000d2000 - 000d4000 (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - bf6b (usable) [0.00] BIOS-e820: bf6b - bf6cc000 (ACPI data) [0.00] BIOS-e820: bf6cc000 - bf70 (ACPI NVS) [0.00] BIOS-e820: bf70 - c000 (reserved) [0.00] BIOS-e820: f000 - f400 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fed0 - fed00400 (reserved) [0.00] BIOS-e820: fed14000 - fed1a000 (reserved) [0.00] BIOS-e820: fed1c000 - fed9 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: ff00 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 00013c00 (usable) -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote: > On Thu, Mar 27, 2008 at 04:35:55PM +0200, Avi Kivity wrote: > >> We can put it under a Kconfig option. >> > > Yes, I thought the MMU_NOTIFIER knob would be enough but we can of > course add more finegrined options if we think it worth to allow > unprivileged users to own /dev/kvm. > With mmu notifiers and the shrinker, there is no reason not to allow ordinary users access to /dev/kvm, so I think it's worthwhile. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Dave Hansen wrote: > On Thu, 2008-03-27 at 12:10 +0200, Avi Kivity wrote: > >> btw, is this with >= 4GB RAM on the host? >> > > Well, are you asking whether I have PAE on or not? :) > > No, I'm asking whether there is a possibility of address truncation :) PAE by itself doesn't affect kvm much, as it always runs the guest in pae mode. Can you try running with mem=2000M or something? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] crash booting Windows with current -git
On Thu, 2008-03-27 at 15:02 +0200, Dor Laor wrote: > On Tue, 2008-03-25 at 12:38 -0700, Dave Hansen wrote: > > I'm getting the following crash with current -git userspace. I'm > > running a stock 2.6.22-14-generic ubuntu kernels with modules from the > > kvm-userspace tree. I believe my BIOS images are also from current > > -git. > > I didn't understand if the kvm modules are from the stock kernel or > synced against kvm kernel git tree? These were stock as they came from the current Linus git tree. > > > > The crash occurs about 10 or 15 seconds after the GUI comes up. > > > > Booting with -no-kvm is OK. > > > > [EMAIL PROTECTED]:~/projects/qemu$ > > ~/src/kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda > > ~/projects/qemu/windows-xp-base-runme.img > > Just for safety please add '-L ~/src/kvm-userspace/qemu/pc-bios OK, I'll do that from now on. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] hugetlbfs not working
Hi,
I'm currently trying to get hugetlbfs working on the current git
version and am quite puzzled to see it not working. It appears as if
the ftruncate call fails:
open("/dev/hugetlbfs//kvm.vI3G8z", O_RDWR|O_CREAT|O_EXCL, 0600) = 7
unlink("/dev/hugetlbfs//kvm.vI3G8z")= 0
ftruncate(7, 157286400) = -1 EINVAL (Invalid argument)
dup(2) = 8
fcntl(8, F_GETFL) = 0x8001 (flags O_WRONLY|
O_LARGEFILE)
close(8)= 0
write(2, "ftruncate: Invalid argument\n", 28ftruncate: Invalid argument
) = 28
close(7)= 0
My host kernel is a 2.6.22.
Is this supposed to work? The first version did not have the ftruncate
call, so maybe it doesn't work at all with hugetlbfs?
Alex
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 0/3] QEMU dedicated IO thread
-- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 3/3] QEMU/libkvm: dont create vcpu0 thread
Since the vcpu0 thread is not special anymore and created by qemu-kvm.c. Index: kvm-userspace.io/libkvm/libkvm.c === --- kvm-userspace.io.orig/libkvm/libkvm.c +++ kvm-userspace.io/libkvm/libkvm.c @@ -388,9 +388,6 @@ int kvm_create(kvm_context_t kvm, unsign if (r < 0) return r; kvm_create_irqchip(kvm); - r = kvm_create_vcpu(kvm, 0); - if (r < 0) - return r; return 0; } -- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 1/3] QEMU/KVM: separate thread for IO handling
Move IO processing from vcpu0 to a dedicated thread.
This removes load on vcpu0 by allowing better cache locality and also
improves latency.
We can now block signal handling for IO events, so sigtimedwait won't
race with handlers:
- Currently the SIGALRM handler fails to set CPU_INTERRUPT_EXIT because
the "next_cpu" variable is not initialized in the KVM path, meaning that
processing of timer expiration might be delayed until the next vcpu0 exit.
- Processing of IO events will not be unnecessarily interrupted.
Index: kvm-userspace.io/qemu/qemu-kvm.c
===
--- kvm-userspace.io.orig/qemu/qemu-kvm.c
+++ kvm-userspace.io/qemu/qemu-kvm.c
@@ -38,6 +38,7 @@ struct qemu_kvm_signal_table {
};
static struct qemu_kvm_signal_table io_signal_table;
+static struct qemu_kvm_signal_table vcpu_signal_table;
#define SIG_IPI (SIGRTMIN+4)
@@ -51,6 +52,8 @@ struct vcpu_info {
int stopped;
} vcpu_info[256];
+pthread_t io_thread;
+
static inline unsigned long kvm_get_thread_id(void)
{
return syscall(SYS_gettid);
@@ -67,12 +70,19 @@ static void sig_ipi_handler(int n)
void kvm_update_interrupt_request(CPUState *env)
{
-if (env && vcpu && env != vcpu->env) {
- if (vcpu_info[env->cpu_index].signalled)
- return;
- vcpu_info[env->cpu_index].signalled = 1;
- if (vcpu_info[env->cpu_index].thread)
- pthread_kill(vcpu_info[env->cpu_index].thread, SIG_IPI);
+int signal = 0;
+
+if (env) {
+if (!vcpu)
+signal = 1;
+if (vcpu && env != vcpu->env && !vcpu_info[env->cpu_index].signalled)
+signal = 1;
+
+if (signal) {
+vcpu_info[env->cpu_index].signalled = 1;
+if (vcpu_info[env->cpu_index].thread)
+pthread_kill(vcpu_info[env->cpu_index].thread, SIG_IPI);
+}
}
}
@@ -105,7 +115,7 @@ static void post_kvm_run(void *opaque, i
static int pre_kvm_run(void *opaque, int vcpu)
{
-CPUState *env = cpu_single_env;
+CPUState *env = qemu_kvm_cpu_env(vcpu);
kvm_arch_pre_kvm_run(opaque, vcpu);
@@ -151,7 +161,8 @@ static int has_work(CPUState *env)
return kvm_arch_has_work(env);
}
-static int kvm_eat_signal(CPUState *env, int timeout)
+static int kvm_eat_signal(struct qemu_kvm_signal_table *waitset, CPUState *env,
+ int timeout)
{
struct timespec ts;
int r, e, ret = 0;
@@ -160,12 +171,12 @@ static int kvm_eat_signal(CPUState *env,
ts.tv_sec = timeout / 1000;
ts.tv_nsec = (timeout % 1000) * 100;
-r = sigtimedwait(&io_signal_table.sigset, &siginfo, &ts);
+r = sigtimedwait(&waitset->sigset, &siginfo, &ts);
if (r == -1 && (errno == EAGAIN || errno == EINTR) && !timeout)
return 0;
e = errno;
pthread_mutex_lock(&qemu_mutex);
-if (vcpu)
+if (env && vcpu)
cpu_single_env = vcpu->env;
if (r == -1 && !(errno == EAGAIN || errno == EINTR)) {
printf("sigtimedwait: %s\n", strerror(e));
@@ -181,7 +192,7 @@ static int kvm_eat_signal(CPUState *env,
if (env && vcpu_info[env->cpu_index].stop) {
vcpu_info[env->cpu_index].stop = 0;
vcpu_info[env->cpu_index].stopped = 1;
- pthread_kill(vcpu_info[0].thread, SIG_IPI);
+ pthread_kill(io_thread, SIGUSR1);
}
pthread_mutex_unlock(&qemu_mutex);
@@ -192,24 +203,16 @@ static int kvm_eat_signal(CPUState *env,
static void kvm_eat_signals(CPUState *env, int timeout)
{
int r = 0;
+struct qemu_kvm_signal_table *waitset = &vcpu_signal_table;
-while (kvm_eat_signal(env, 0))
+while (kvm_eat_signal(waitset, env, 0))
r = 1;
if (!r && timeout) {
- r = kvm_eat_signal(env, timeout);
+ r = kvm_eat_signal(waitset, env, timeout);
if (r)
- while (kvm_eat_signal(env, 0))
+ while (kvm_eat_signal(waitset, env, 0))
;
}
-/*
- * we call select() even if no signal was received, to account for
- * for which there is no signal handler installed.
- */
-pthread_mutex_lock(&qemu_mutex);
-cpu_single_env = vcpu->env;
-if (env->cpu_index == 0)
- main_loop_wait(0);
-pthread_mutex_unlock(&qemu_mutex);
}
static void kvm_main_loop_wait(CPUState *env, int timeout)
@@ -225,29 +228,29 @@ static int all_threads_paused(void)
{
int i;
-for (i = 1; i < smp_cpus; ++i)
+for (i = 0; i < smp_cpus; ++i)
if (vcpu_info[i].stopped)
return 0;
return 1;
}
-static void pause_other_threads(void)
+static void pause_all_threads(void)
{
int i;
-for (i = 1; i < smp_cpus; ++i) {
+for (i = 0; i < smp_cpus; ++i) {
vcpu_info[i].stop = 1;
pthread_kill(vcpu_info[i].thread, SIG_IPI);
}
while (!all_threads_paused())
- kvm_eat_signals(vcpu->env, 0);
+ kvm_eat_signal(&io_signal_table, NULL, 1000);
}
-static void resume_other_threads(void)
+sta
[kvm-devel] [patch 2/3] QEMU/KVM: add function to handle signals
SIGUSR1 has no handler, and the SIGUSR2 one does nothing useful anymore
(thats also true for SIGIO on tap fd, which runs host_alarm_handler
unnecessarily).
Index: kvm-userspace.io/qemu/qemu-kvm.c
===
--- kvm-userspace.io.orig/qemu/qemu-kvm.c
+++ kvm-userspace.io/qemu/qemu-kvm.c
@@ -161,13 +161,30 @@ static int has_work(CPUState *env)
return kvm_arch_has_work(env);
}
+static int kvm_process_signal(int si_signo)
+{
+struct sigaction sa;
+
+switch (si_signo) {
+case SIGUSR2:
+pthread_cond_signal(&qemu_aio_cond);
+break;
+case SIGALRM:
+case SIGIO:
+sigaction(si_signo, NULL, &sa);
+sa.sa_handler(si_signo);
+break;
+}
+
+return 1;
+}
+
static int kvm_eat_signal(struct qemu_kvm_signal_table *waitset, CPUState *env,
int timeout)
{
struct timespec ts;
int r, e, ret = 0;
siginfo_t siginfo;
-struct sigaction sa;
ts.tv_sec = timeout / 1000;
ts.tv_nsec = (timeout % 1000) * 100;
@@ -182,13 +199,9 @@ static int kvm_eat_signal(struct qemu_kv
printf("sigtimedwait: %s\n", strerror(e));
exit(1);
}
-if (r != -1) {
- sigaction(siginfo.si_signo, NULL, &sa);
- sa.sa_handler(siginfo.si_signo);
- if (siginfo.si_signo == SIGUSR2)
- pthread_cond_signal(&qemu_aio_cond);
- ret = 1;
-}
+if (r != -1)
+ret = kvm_process_signal(siginfo.si_signo);
+
if (env && vcpu_info[env->cpu_index].stop) {
vcpu_info[env->cpu_index].stop = 0;
vcpu_info[env->cpu_index].stopped = 1;
--
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] hugetlbfs not working
Alexander Graf wrote:
> Hi,
>
> I'm currently trying to get hugetlbfs working on the current git
> version and am quite puzzled to see it not working. It appears as if
> the ftruncate call fails:
>
> open("/dev/hugetlbfs//kvm.vI3G8z", O_RDWR|O_CREAT|O_EXCL, 0600) = 7
> unlink("/dev/hugetlbfs//kvm.vI3G8z")= 0
> ftruncate(7, 157286400) = -1 EINVAL (Invalid argument)
> dup(2) = 8
> fcntl(8, F_GETFL) = 0x8001 (flags O_WRONLY|
> O_LARGEFILE)
> close(8)= 0
> write(2, "ftruncate: Invalid argument\n", 28ftruncate: Invalid argument
> ) = 28
> close(7)= 0
>
> My host kernel is a 2.6.22.
>
> Is this supposed to work? The first version did not have the ftruncate
> call, so maybe it doesn't work at all with hugetlbfs?
>
Are you on i386 non-pae? that has 4MB pages, while you're asking for
for 37.5 4MB pages.
Try adding 2MB to the requested memory size.
--
error compiling committee.c: too many arguments to function
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 1/3] QEMU/KVM: separate thread for IO handling
Marcelo Tosatti wrote: > Move IO processing from vcpu0 to a dedicated thread. > > This removes load on vcpu0 by allowing better cache locality and also > improves latency. > > Does live migration (and stop/cont) still work with this? > We can now block signal handling for IO events, so sigtimedwait won't > race with handlers: > > - Currently the SIGALRM handler fails to set CPU_INTERRUPT_EXIT because > the "next_cpu" variable is not initialized in the KVM path, meaning that > processing of timer expiration might be delayed until the next vcpu0 exit. > I still don't understand this. Timer expiration ought to be processed in the iothread, when SIGALRM is dequeued, and be completely unrelated to whatever vcpu 0 is doing. > - Processing of IO events will not be unnecessarily interrupted. > What do you mean by this? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 2/3] QEMU/KVM: add function to handle signals
Marcelo Tosatti wrote: > SIGUSR1 has no handler, and the SIGUSR2 one does nothing useful anymore > (thats also true for SIGIO on tap fd, which runs host_alarm_handler > unnecessarily). > The sigaction(); sa.sa_handler() stuff was added as a stopgap; do we actually need to run _any_ signal handlers? I think that main_loop_wait() does all that's necessary. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Avi Kivity <[EMAIL PROTECTED]> writes: (thought i sent a reply before, but i don't see it now. sorry if you see it twice) > Andrea notes that freeing the page before flushing the tlb is a race, as the > guest can sneak in one last write before the tlb is flushed, writing to a > page that may belong to someone else. > > Fix be reversing the order of freeing and flushing the tlb. Since the tlb > flush is expensive, queue the pages to be freed so we need to flush just once. You have to do the same for the page tables too, because several modern CPUs cache the higher level of the page tables and only invalidate the cache on any TLB flush. Strictly it is only needed for the higher levels, but doing it for all is safer. -Andi - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] hugetlbfs not working
On Mar 27, 2008, at 4:19 PM, Avi Kivity wrote:
> Alexander Graf wrote:
>> Hi,
>>
>> I'm currently trying to get hugetlbfs working on the current git
>> version and am quite puzzled to see it not working. It appears as
>> if the ftruncate call fails:
>>
>> open("/dev/hugetlbfs//kvm.vI3G8z", O_RDWR|O_CREAT|O_EXCL, 0600) = 7
>> unlink("/dev/hugetlbfs//kvm.vI3G8z")= 0
>> ftruncate(7, 157286400) = -1 EINVAL (Invalid
>> argument)
>> dup(2) = 8
>> fcntl(8, F_GETFL) = 0x8001 (flags O_WRONLY|
>> O_LARGEFILE)
>> close(8)= 0
>> write(2, "ftruncate: Invalid argument\n", 28ftruncate: Invalid
>> argument
>> ) = 28
>> close(7)= 0
>>
>> My host kernel is a 2.6.22.
>>
>> Is this supposed to work? The first version did not have the
>> ftruncate call, so maybe it doesn't work at all with hugetlbfs?
>>
>
> Are you on i386 non-pae? that has 4MB pages, while you're asking
> for for 37.5 4MB pages.
>
> Try adding 2MB to the requested memory size.
I'm on x86_64 and /proc/meminfo tells me:
HugePages_Total: 1435
HugePages_Free: 1435
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
I also reserved all available huge pages:
% cat /proc/sys/vm/nr_hugepages
1435
Changing the guest memory size using -m does not help.
Alex
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 1/3] QEMU/KVM: separate thread for IO handling
On Thu, Mar 27, 2008 at 05:23:38PM +0200, Avi Kivity wrote: > Marcelo Tosatti wrote: > >Move IO processing from vcpu0 to a dedicated thread. > > > >This removes load on vcpu0 by allowing better cache locality and also > >improves latency. > > > > > > Does live migration (and stop/cont) still work with this? Yes, live migration works with UP. SMP migration is broken, but its not an issue related to pausing/resuming of threads (its broken even without the change). What happens is that all threads run successfully on the target (you can see the guest reading the PM timer), but its locked wasting lots of CPU cycles (KVM is emulating some instruction(s)). Will look into it later. > > >We can now block signal handling for IO events, so sigtimedwait won't > >race with handlers: > > > >- Currently the SIGALRM handler fails to set CPU_INTERRUPT_EXIT because > >the "next_cpu" variable is not initialized in the KVM path, meaning that > >processing of timer expiration might be delayed until the next vcpu0 exit. > > > > I still don't understand this. Timer expiration ought to be processed > in the iothread, when SIGALRM is dequeued, and be completely unrelated > to whatever vcpu 0 is doing. Yes, now it is unrelated. But before the patch it wasnt. So "currently the SIGALRM handler..." means the current code in kvm-userspace.git. > >- Processing of IO events will not be unnecessarily interrupted. > > > > What do you mean by this? That SIGIO, SIGALRM and SIGUSR2 signals will not interrupt main_loop_wait(), since they are now blocked. Better latency, less time holding the mutex lock. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 1/3] QEMU/KVM: separate thread for IO handling
Marcelo Tosatti wrote: >>> >>> >> I still don't understand this. Timer expiration ought to be processed >> in the iothread, when SIGALRM is dequeued, and be completely unrelated >> to whatever vcpu 0 is doing. >> > > Yes, now it is unrelated. But before the patch it wasnt. So "currently > the SIGALRM handler..." means the current code in kvm-userspace.git. > > I see now. Okay, will merge. >>> - Processing of IO events will not be unnecessarily interrupted. >>> >>> >> What do you mean by this? >> > > That SIGIO, SIGALRM and SIGUSR2 signals will not interrupt > main_loop_wait(), since they are now blocked. Better latency, less time > holding the mutex lock Signals are blocked in current git, they can only interrupt the guest, not the host. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Thu, 2008-03-27 at 11:36 +0200, Avi Kivity wrote: > I dug out my i386 install and tried it. Doesn't reproduce for me on > either kvm.git or -rc7. > > Do you have a working setup that we can bisect? I don't really have a working revision to bisect against. I'm not sure that it ever worked. It's also on my actual laptop, so it's a bit of a pain to get any other work done while I'm bisecting. :) I'll move the Windows image over to another machine today and see if I can reproduce elsewhere. I'll also check some older versions of KVM to see if any of those work. If I do that, should I keep the kvm userspace, modules and BIOSes all synchronized from each version that I test? -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Dave Hansen wrote: > On Thu, 2008-03-27 at 11:36 +0200, Avi Kivity wrote: > >> I dug out my i386 install and tried it. Doesn't reproduce for me on >> either kvm.git or -rc7. >> >> Do you have a working setup that we can bisect? >> > > I don't really have a working revision to bisect against. I'm not sure > that it ever worked. I'm fairly sure Windows works on kvm... How did you generate the image? > It's also on my actual laptop, so it's a bit of a > pain to get any other work done while I'm bisecting. :) > > I'll move the Windows image over to another machine today and see if I > can reproduce elsewhere. I'll also check some older versions of KVM to > see if any of those work. If I do that, should I keep the kvm > userspace, modules and BIOSes all synchronized from each version that I > test? > You can keep the userspace (qemu + bios) fixed and change the kernel, or vice versa. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 2/3] QEMU/KVM: add function to handle signals
On Thu, Mar 27, 2008 at 05:25:20PM +0200, Avi Kivity wrote: > Marcelo Tosatti wrote: > >SIGUSR1 has no handler, and the SIGUSR2 one does nothing useful anymore > >(thats also true for SIGIO on tap fd, which runs host_alarm_handler > >unnecessarily). > > > > The sigaction(); sa.sa_handler() stuff was added as a stopgap; do we > actually need to run _any_ signal handlers? Yes, we need to run host_alarm_handler() to set ALARM_EXPIRED, so the alarm timer gets rearmed by main_loop_wait. Thats the only one. > I think that main_loop_wait() does all that's necessary. We need this patch to separate SIGALRM from network SIGIO: http://www.mail-archive.com/[EMAIL PROTECTED]/msg16020.html Anders, can you resubmit this patch please? Any idea why it has not been merged yet? With this in place we can get rid of the sigaction syscall for SIGIO. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 0/3] QEMU dedicated IO thread
Marcelo Tosatti wrote: Applied all, thanks. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 3/3] QEMU/libkvm: dont create vcpu0 thread
Marcelo Tosatti wrote: > Since the vcpu0 thread is not special anymore and created by qemu-kvm.c. > > Index: kvm-userspace.io/libkvm/libkvm.c > === > --- kvm-userspace.io.orig/libkvm/libkvm.c > +++ kvm-userspace.io/libkvm/libkvm.c > @@ -388,9 +388,6 @@ int kvm_create(kvm_context_t kvm, unsign > if (r < 0) > return r; > kvm_create_irqchip(kvm); > - r = kvm_create_vcpu(kvm, 0); > - if (r < 0) > - return r; > > return 0; > } > > This isn't a standalone patch, so I folded it into the first patch (I expected this patch would have the corresponding addition of a kvm_create_vcpu(kvm, 0) to qemu). -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 2/3] QEMU/KVM: add function to handle signals
Marcelo Tosatti wrote: > On Thu, Mar 27, 2008 at 05:25:20PM +0200, Avi Kivity wrote: > >> Marcelo Tosatti wrote: >> >>> SIGUSR1 has no handler, and the SIGUSR2 one does nothing useful anymore >>> (thats also true for SIGIO on tap fd, which runs host_alarm_handler >>> unnecessarily). >>> >>> >> The sigaction(); sa.sa_handler() stuff was added as a stopgap; do we >> actually need to run _any_ signal handlers? >> > > Yes, we need to run host_alarm_handler() to set ALARM_EXPIRED, so the > alarm timer gets rearmed by main_loop_wait. Thats the only one. > > We can call it explicitly. I'm worried about the slirp code. I think I checked it once but it is sufficiently obfuscated to be worrying. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] hugetlbfs not working
Alexander Graf wrote:
> On Mar 27, 2008, at 4:19 PM, Avi Kivity wrote:
>
>
>> Alexander Graf wrote:
>>
>>> Hi,
>>>
>>> I'm currently trying to get hugetlbfs working on the current git
>>> version and am quite puzzled to see it not working. It appears as
>>> if the ftruncate call fails:
>>>
>>> open("/dev/hugetlbfs//kvm.vI3G8z", O_RDWR|O_CREAT|O_EXCL, 0600) = 7
>>> unlink("/dev/hugetlbfs//kvm.vI3G8z")= 0
>>> ftruncate(7, 157286400) = -1 EINVAL (Invalid
>>> argument)
>>> dup(2) = 8
>>> fcntl(8, F_GETFL) = 0x8001 (flags O_WRONLY|
>>> O_LARGEFILE)
>>> close(8)= 0
>>> write(2, "ftruncate: Invalid argument\n", 28ftruncate: Invalid
>>> argument
>>> ) = 28
>>> close(7)= 0
>>>
>>> My host kernel is a 2.6.22.
>>>
>>> Is this supposed to work? The first version did not have the
>>> ftruncate call, so maybe it doesn't work at all with hugetlbfs?
>>>
>>>
>> Are you on i386 non-pae? that has 4MB pages, while you're asking
>> for for 37.5 4MB pages.
>>
>> Try adding 2MB to the requested memory size.
>>
>
> I'm on x86_64 and /proc/meminfo tells me:
>
> HugePages_Total: 1435
> HugePages_Free: 1435
> HugePages_Rsvd: 0
> Hugepagesize: 2048 kB
>
> I also reserved all available huge pages:
>
> % cat /proc/sys/vm/nr_hugepages
> 1435
>
> Changing the guest memory size using -m does not help.
>
If you don't bail when ftruncate fails, does it work as expected for
you? Perhaps older versions of hugetlbfs didn't support truncate.
Regards,
Anthony Liguori
> Alex
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] hugetlbfs not working
Anthony Liguori wrote: > > If you don't bail when ftruncate fails, does it work as expected for > you? Perhaps older versions of hugetlbfs didn't support truncate. If you don't truncate, how can you change the file size? hugetlbfs doesn't support write(). I vaugely recall using ftruncate() on 2.4. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] QEMU/KVM: virtio-blk asynchronous IO
Use asynchronous IO in the virtio block QEMU driver.
virtio_blk_handle_output should not block for long periods, since it
holds the mutex lock prohibiting other vcpu's from doing IO to QEMU
devices. Without AIO write intensive benchmarks make guests hang for
several seconds. Write performance also increases significantly.
Also report errors properly.
To take full advantage of parallel IO we need to allow for more than AIO
thread per-fd, or use direct IO (-nocache) which uses kernel AIO.
Separate patch allows virtio-block guest driver to queue more than one
element in the virtio ring.
Anthony, this patch abuses the virtqueue_push() interface by passing a
VirtQueueElement with only "index" member valid, since we know this is
all it uses. Doing so avoids allocation, zeroing and copy of an entire
VirtQueueElement structure. What do you say?
Index: kvm-userspace.io/qemu/hw/virtio-blk.c
===
--- kvm-userspace.io.orig/qemu/hw/virtio-blk.c
+++ kvm-userspace.io/qemu/hw/virtio-blk.c
@@ -77,53 +77,100 @@ static VirtIOBlock *to_virtio_blk(VirtIO
return (VirtIOBlock *)vdev;
}
+typedef struct VirtIOBlockReq
+{
+VirtIODevice *vdev;
+VirtQueue *vq;
+struct iovec in_sg_status;
+unsigned int pending;
+unsigned int len;
+unsigned int elem_idx;
+int status;
+} VirtIOBlockReq;
+
+static void virtio_blk_rw_complete(void *opaque, int ret)
+{
+VirtIOBlockReq *req = opaque;
+struct virtio_blk_inhdr *in;
+VirtQueueElement elem;
+
+req->status |= ret;
+if (--req->pending > 0)
+return;
+
+elem.index = req->elem_idx;
+in = (void *)req->in_sg_status.iov_base;
+
+in->status = req->status ? VIRTIO_BLK_S_IOERR : VIRTIO_BLK_S_OK;
+virtqueue_push(req->vq, &elem, req->len);
+virtio_notify(req->vdev, req->vq);
+qemu_free(req);
+}
+
static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIOBlock *s = to_virtio_blk(vdev);
VirtQueueElement elem;
+VirtIOBlockReq *req;
unsigned int count;
while ((count = virtqueue_pop(vq, &elem)) != 0) {
struct virtio_blk_inhdr *in;
struct virtio_blk_outhdr *out;
- unsigned int wlen;
off_t off;
int i;
+ /*
+* FIXME: limit the number of in-flight requests
+*/
+ req = qemu_malloc(sizeof(VirtIOBlockReq));
+ if (!req)
+ return;
+ memset(req, 0, sizeof(*req));
+ memcpy(&req->in_sg_status, &elem.in_sg[elem.in_num - 1],
+ sizeof(req->in_sg_status));
+ req->vdev = vdev;
+ req->vq = vq;
+ req->elem_idx = elem.index;
+
out = (void *)elem.out_sg[0].iov_base;
in = (void *)elem.in_sg[elem.in_num - 1].iov_base;
off = out->sector;
if (out->type & VIRTIO_BLK_T_SCSI_CMD) {
- wlen = sizeof(*in);
+ unsigned int len = sizeof(*in);
+
in->status = VIRTIO_BLK_S_UNSUPP;
+ virtqueue_push(vq, &elem, len);
+ virtio_notify(vdev, vq);
+ qemu_free(req);
+
} else if (out->type & VIRTIO_BLK_T_OUT) {
- wlen = sizeof(*in);
+ req->pending = elem.out_num - 1;
for (i = 1; i < elem.out_num; i++) {
- bdrv_write(s->bs, off,
+ bdrv_aio_write(s->bs, off,
elem.out_sg[i].iov_base,
- elem.out_sg[i].iov_len / 512);
+ elem.out_sg[i].iov_len / 512,
+ virtio_blk_rw_complete,
+ req);
off += elem.out_sg[i].iov_len / 512;
+ req->len += elem.out_sg[i].iov_len;
}
- in->status = VIRTIO_BLK_S_OK;
} else {
- wlen = sizeof(*in);
+ req->pending = elem.in_num - 1;
for (i = 0; i < elem.in_num - 1; i++) {
- bdrv_read(s->bs, off,
+ bdrv_aio_read(s->bs, off,
elem.in_sg[i].iov_base,
- elem.in_sg[i].iov_len / 512);
+ elem.in_sg[i].iov_len / 512,
+ virtio_blk_rw_complete,
+ req);
off += elem.in_sg[i].iov_len / 512;
- wlen += elem.in_sg[i].iov_len;
+ req->len += elem.in_sg[i].iov_len;
}
-
- in->status = VIRTIO_BLK_S_OK;
}
-
- virtqueue_push(vq, &elem, wlen);
- virtio_notify(vdev, vq);
}
}
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] virtio-blk: allow more than one in-flight request
Allow more than one in-flight request in the virtio ring. This allows
the host driver to submit requests in parallel.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 3b1a68d..5bb041f 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -30,6 +30,8 @@ struct virtio_blk
struct scatterlist sg[VIRTIO_MAX_SG];
};
+#define VIRTIO_BLK_POOL_SIZE 32
+
struct virtblk_req
{
struct list_head list;
@@ -202,7 +204,8 @@ static int virtblk_probe(struct virtio_device *vdev)
goto out_free_vblk;
}
- vblk->pool = mempool_create_kmalloc_pool(1,sizeof(struct virtblk_req));
+ vblk->pool = mempool_create_kmalloc_pool(VIRTIO_BLK_POOL_SIZE,
+sizeof(struct virtblk_req));
if (!vblk->pool) {
err = -ENOMEM;
goto out_free_vq;
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Thu, 2008-03-27 at 17:53 +0200, Avi Kivity wrote: > Dave Hansen wrote: > > On Thu, 2008-03-27 at 11:36 +0200, Avi Kivity wrote: > > > >> I dug out my i386 install and tried it. Doesn't reproduce for me on > >> either kvm.git or -rc7. > >> > >> Do you have a working setup that we can bisect? > >> > > I don't really have a working revision to bisect against. I'm not sure > > that it ever worked. > > I'm fairly sure Windows works on kvm... Oh, I didn't mean to imply that Windows doesn't work, just that the particular perverted way in which I'm poking it may have never worked. :) > How did you generate the image? The original install was done in a kqemu-accelerated host. > > It's also on my actual laptop, so it's a bit of a > > pain to get any other work done while I'm bisecting. :) > > > > I'll move the Windows image over to another machine today and see if I > > can reproduce elsewhere. I'll also check some older versions of KVM to > > see if any of those work. If I do that, should I keep the kvm > > userspace, modules and BIOSes all synchronized from each version that I > > test? > > > > You can keep the userspace (qemu + bios) fixed and change the kernel, or > vice versa. > -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Thu, 2008-03-27 at 16:59 +0200, Avi Kivity wrote: > Dave Hansen wrote: > > On Thu, 2008-03-27 at 12:10 +0200, Avi Kivity wrote: > >> btw, is this with >= 4GB RAM on the host? > >> > > Well, are you asking whether I have PAE on or not? :) > > No, I'm asking whether there is a possibility of address truncation :) > > PAE by itself doesn't affect kvm much, as it always runs the guest in > pae mode. > > Can you try running with mem=2000M or something? Oh, sure. I'll give that a shot. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] QEMU/KVM: virtio-blk asynchronous IO
Marcelo Tosatti wrote:
> Use asynchronous IO in the virtio block QEMU driver.
>
> virtio_blk_handle_output should not block for long periods, since it
> holds the mutex lock prohibiting other vcpu's from doing IO to QEMU
> devices. Without AIO write intensive benchmarks make guests hang for
> several seconds. Write performance also increases significantly.
>
> Also report errors properly.
>
> To take full advantage of parallel IO we need to allow for more than AIO
> thread per-fd, or use direct IO (-nocache) which uses kernel AIO.
>
> Separate patch allows virtio-block guest driver to queue more than one
> element in the virtio ring.
>
> Anthony, this patch abuses the virtqueue_push() interface by passing a
> VirtQueueElement with only "index" member valid, since we know this is
> all it uses. Doing so avoids allocation, zeroing and copy of an entire
> VirtQueueElement structure. What do you say?
>
I've got a virtio patch series that changes the virtqueue_pop()
interface to return a pointer to a VirtQueueElement which I believe
addresses your use-case.
I can just fold your patch into my series (I'll be sending it out this
afternoon).
Regards,
Anthony Liguori
> Index: kvm-userspace.io/qemu/hw/virtio-blk.c
> ===
> --- kvm-userspace.io.orig/qemu/hw/virtio-blk.c
> +++ kvm-userspace.io/qemu/hw/virtio-blk.c
> @@ -77,53 +77,100 @@ static VirtIOBlock *to_virtio_blk(VirtIO
> return (VirtIOBlock *)vdev;
> }
>
> +typedef struct VirtIOBlockReq
> +{
> +VirtIODevice *vdev;
> +VirtQueue *vq;
> +struct iovec in_sg_status;
> +unsigned int pending;
> +unsigned int len;
> +unsigned int elem_idx;
> +int status;
> +} VirtIOBlockReq;
> +
> +static void virtio_blk_rw_complete(void *opaque, int ret)
> +{
> +VirtIOBlockReq *req = opaque;
> +struct virtio_blk_inhdr *in;
> +VirtQueueElement elem;
> +
> +req->status |= ret;
> +if (--req->pending > 0)
> +return;
> +
> +elem.index = req->elem_idx;
> +in = (void *)req->in_sg_status.iov_base;
> +
> +in->status = req->status ? VIRTIO_BLK_S_IOERR : VIRTIO_BLK_S_OK;
> +virtqueue_push(req->vq, &elem, req->len);
> +virtio_notify(req->vdev, req->vq);
> +qemu_free(req);
> +}
> +
> static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> {
> VirtIOBlock *s = to_virtio_blk(vdev);
> VirtQueueElement elem;
> +VirtIOBlockReq *req;
> unsigned int count;
>
> while ((count = virtqueue_pop(vq, &elem)) != 0) {
> struct virtio_blk_inhdr *in;
> struct virtio_blk_outhdr *out;
> - unsigned int wlen;
> off_t off;
> int i;
>
> + /*
> + * FIXME: limit the number of in-flight requests
> + */
> + req = qemu_malloc(sizeof(VirtIOBlockReq));
> + if (!req)
> + return;
> + memset(req, 0, sizeof(*req));
> + memcpy(&req->in_sg_status, &elem.in_sg[elem.in_num - 1],
> +sizeof(req->in_sg_status));
> + req->vdev = vdev;
> + req->vq = vq;
> + req->elem_idx = elem.index;
> +
> out = (void *)elem.out_sg[0].iov_base;
> in = (void *)elem.in_sg[elem.in_num - 1].iov_base;
> off = out->sector;
>
> if (out->type & VIRTIO_BLK_T_SCSI_CMD) {
> - wlen = sizeof(*in);
> + unsigned int len = sizeof(*in);
> +
> in->status = VIRTIO_BLK_S_UNSUPP;
> + virtqueue_push(vq, &elem, len);
> + virtio_notify(vdev, vq);
> + qemu_free(req);
> +
> } else if (out->type & VIRTIO_BLK_T_OUT) {
> - wlen = sizeof(*in);
> + req->pending = elem.out_num - 1;
>
> for (i = 1; i < elem.out_num; i++) {
> - bdrv_write(s->bs, off,
> + bdrv_aio_write(s->bs, off,
> elem.out_sg[i].iov_base,
> -elem.out_sg[i].iov_len / 512);
> +elem.out_sg[i].iov_len / 512,
> +virtio_blk_rw_complete,
> +req);
> off += elem.out_sg[i].iov_len / 512;
> + req->len += elem.out_sg[i].iov_len;
> }
>
> - in->status = VIRTIO_BLK_S_OK;
> } else {
> - wlen = sizeof(*in);
> + req->pending = elem.in_num - 1;
>
> for (i = 0; i < elem.in_num - 1; i++) {
> - bdrv_read(s->bs, off,
> + bdrv_aio_read(s->bs, off,
> elem.in_sg[i].iov_base,
> - elem.in_sg[i].iov_len / 512);
> + elem.in_sg[i].iov_len / 512,
> + virtio_blk_rw_complete,
> + req);
> off += elem.in_sg[i].iov_len / 512;
> - wlen += elem.in_sg[i].iov_len;
> + req->len += elem.in_sg[i].iov_len;
> }
> -
> - in->status = VIRTIO_BLK_S_OK;
> }
> -
> - virtqueue_push(vq, &elem, wlen);
> - virtio_notify(vdev, vq);
> }
> }
>
>
--
Re: [kvm-devel] hugetlbfs not working
On Thu, Mar 27, 2008 at 06:09:56PM +0200, Avi Kivity wrote: > Anthony Liguori wrote: > > > > If you don't bail when ftruncate fails, does it work as expected for > > you? Perhaps older versions of hugetlbfs didn't support truncate. > > If you don't truncate, how can you change the file size? hugetlbfs > doesn't support write(). > > I vaugely recall using ftruncate() on 2.4. hugetlbfs will automatically adjust the file size on mmap(). - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 2/3] QEMU/KVM: add function to handle signals
Marcelo Tosatti wrote: > SIGUSR1 has no handler, and the SIGUSR2 one does nothing useful anymore > (thats also true for SIGIO on tap fd, which runs host_alarm_handler > unnecessarily). > > This one prevents alt+F4 from closing the sdl window (X over ssh), so I'm backing it out. I'm getting some regression test failures, I'll see if they're caused by patch 1 or 2. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-blk: allow more than one in-flight request
Am Donnerstag, 27. März 2008 schrieb Marcelo Tosatti:
>
> Allow more than one in-flight request in the virtio ring. This allows
> the host driver to submit requests in parallel.
[...]
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 3b1a68d..5bb041f 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
[...]
> @@ -202,7 +204,8 @@ static int virtblk_probe(struct virtio_device *vdev)
> goto out_free_vblk;
> }
>
> - vblk->pool = mempool_create_kmalloc_pool(1,sizeof(struct virtblk_req));
> + vblk->pool = mempool_create_kmalloc_pool(VIRTIO_BLK_POOL_SIZE,
> +sizeof(struct virtblk_req));
> if (!vblk->pool) {
> err = -ENOMEM;
> goto out_free_vq;
[...]
Huh? I dont understand. You only change the number of pre-allocated pool
entries. mempool_alloc should allow several allocations, even with 1 as
initialization value. The pre-initialized value is only for oom situations.
No?
Christian
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Долевое строительство домов
Бухгалтeрский учeт и налогообложeниe при осущeствлeнии капитальных вложeний и жилищного строитeльства Однoднeвный сeминар / 7 апрeля 2008 г. / Мoсква Прoграмма сeминара: 1. Понятиe инвeстиций в капитальныe вложeния. Субъeкты капитальных вложeний. Инвeстор, пользоватeль, заказчик, подрядчик. Взаимоотношeния мeжду субъeктами инвeстиционной дeятeльности. Порядок отражeния в учeтe договоров, заключаeмых мeжду субъeктами инвeстиционной дeятeльности. 2. Долeвоe строитeльство многоквартирных домов и иных объeктов нeдвижимости. Застройщик, участник долeвого строитeльства. Договор участия в долeвом строитeльствe. Отражeниe в учeтe договора о долeвом участии в строитeльствe. 3. Заказчик. eго функции, права и обязанности. Взаимоотношeния заказчика с другими участниками строитeльного процeсса. Бухгалтeрский и налоговый учeт у заказчика. 4. Подрядчик. eго функции, права и обязанности. Взаимоотношeния подрядчика с другими участниками строитeльного процeсса. Прoдoлжитeльнoсть oбучeния: с 10 дo 17 часoв (с пeрeрывoм на oбeд и кoфe-паузу). Мeстo oбучeния: г. Мoсква, 5 мин. пeшкoм oт м. Акадeмичeская. Стoимoсть oбучeния: 4900 руб. (с НДС). (В стoимoсть вхoдит: раздатoчный матeриал, кoфe-пауза, oбeд в рeстoранe). При oтсутствии вoзмoжнoсти пoсeтить сeминар, мы прeдлагаeм приoбрeсти eгo видeoвeрсию на DVD/CD дисках или видeoкассeтах (прилагаeтся автoрский раздатoчный матeриал). Цeна видeoкурса - 3500 рублeй, с учeтoм НДС. Для рeгистрации на сeминар нeoбхoдимo oтправить нам пo факсу или элeктрoннoй пoчтe: рeквизиты oрганизации, тeму и дату сeминара, пoлнoe ФИo участникoв, кoнтактный тeлeфoн и факс. Для заказа видeoкурса нeoбхoдимo oтправить нам пo факсу или элeктрoннoй пoчтe: рeквизиты oрганизации, тeму видeoкурса, указать нoситeль (ДВД или СД диски), тeлeфoн, факс, кoнтактнoe лицo и тoчный адрeс дoставки. Пoлучить дoпoлнитeльную инфoрмацию и зарeгистрирoваться мoжнo: пo т/ф: (495) 543-88-46 пo элeктрoннoй пoчтe: [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 0/3] QEMU dedicated IO thread
Avi Kivity wrote: > Marcelo Tosatti wrote: > > > Applied all, thanks. > > And backed out, as the regression tests indicate a bazillion failures. I haven't investigated , but I think things are just slow so the tests time out. -- Any sufficiently difficult bug is indistinguishable from a feature. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 0/3] QEMU dedicated IO thread
On Thu, Mar 27, 2008 at 09:06:58PM +0200, Avi Kivity wrote: > Avi Kivity wrote: > >Marcelo Tosatti wrote: > > > > > >Applied all, thanks. > > > > > And backed out, as the regression tests indicate a bazillion failures. > I haven't investigated , but I think things are just slow so the tests > time out. What tests did you run? - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-blk: allow more than one in-flight request
On Thu, Mar 27, 2008 at 06:45:14PM +0100, Christian Borntraeger wrote:
> Am Donnerstag, 27. März 2008 schrieb Marcelo Tosatti:
> >
> > Allow more than one in-flight request in the virtio ring. This allows
> > the host driver to submit requests in parallel.
> [...]
> > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > index 3b1a68d..5bb041f 100644
> > --- a/drivers/block/virtio_blk.c
> > +++ b/drivers/block/virtio_blk.c
> [...]
> > @@ -202,7 +204,8 @@ static int virtblk_probe(struct virtio_device *vdev)
> > goto out_free_vblk;
> > }
> >
> > - vblk->pool = mempool_create_kmalloc_pool(1,sizeof(struct virtblk_req));
> > + vblk->pool = mempool_create_kmalloc_pool(VIRTIO_BLK_POOL_SIZE,
> > +sizeof(struct virtblk_req));
> > if (!vblk->pool) {
> > err = -ENOMEM;
> > goto out_free_vq;
> [...]
>
> Huh? I dont understand. You only change the number of pre-allocated pool
> entries. mempool_alloc should allow several allocations, even with 1 as
> initialization value. The pre-initialized value is only for oom situations.
> No?
Thats right, the mempool allocation will fail under memory pressure
(since __GFP_NOMEMALLOC is passed from mempool_allocate), but under
normal circumstances it will allocate more than one entry.
So ignore the patch. Sorry for the noise.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] occludent
Hello, Hohe hoholulu He can't help it it's second nature to him. Charles climb, kermana view of the kerman plain from the honest over batteries though i don't understand the reason that i loved the vicious devil of a the lower exit of which we had seen from below. time, under judicious and intelligent management, sleep, just a sleep. One well deserved. You alive natives. Footnote 190: he afterwards learned the illustrations showing the immensity of the threewalled death. The second storm of his life began, howling of vivid pictures of his life in germany and in return to london with firsthand knowledge of the still, at thatsee that fellow coming out of the unusually strong views on the subject poirot nodded activity that has been manifested in the fortifications,. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] hugetlbfs not working
On Thu, Mar 27, 2008 at 06:09:56PM +0200, Avi Kivity wrote:
> Anthony Liguori wrote:
> >
> > If you don't bail when ftruncate fails, does it work as expected for
> > you? Perhaps older versions of hugetlbfs didn't support truncate.
>
> If you don't truncate, how can you change the file size? hugetlbfs
> doesn't support write().
>
> I vaugely recall using ftruncate() on 2.4.
commit 7aa91e104028b87ff13f5eeb7a0d7ffe7b5a2348
Author: Ken Chen <[EMAIL PROTECTED]>
Date: Tue Oct 16 01:26:21 2007 -0700
hugetlb: allow extending ftruncate on hugetlbfs
For historical reason, expanding ftruncate that increases file size on
hugetlbfs is not allowed due to pages were pre-faulted and lack of fault
handler. Now that we have demand faulting on hugetlb since 2.6.15, there
is no reason to hold back that limitation.
This will make hugetlbfs behave more like a normal fs. I'm writing a user
level code that uses hugetlbfs but will fall back to tmpfs if there are no
hugetlb page available in the system. Having hugetlbfs specific ftruncate
behavior is a bit quirky and I would like to remove that artificial
limitation.
Signed-off-by: <[EMAIL PROTECTED]>
Acked-by: Wiliam Irwin <[EMAIL PROTECTED]>
Cc: Adam Litke <[EMAIL PROTECTED]>
Cc: David Gibson <[EMAIL PROTECTED]>
Cc: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
mmap() should fail if anything goes wrong with ftruncate and the file
length is not extented on tmpfs.
--- vl.c.orig 2008-03-27 18:51:31.0 -0300
+++ vl.c2008-03-27 18:52:40.0 -0300
@@ -8749,11 +8749,7 @@
memory = (memory+hpagesize-1) & ~(hpagesize-1);
-if (ftruncate(fd, memory) == -1) {
- perror("ftruncate");
- close(fd);
- return NULL;
-}
+ftruncate(fd, memory);
area = mmap(0, memory, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
if (area == MAP_FAILED) {
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM: MMU: fix large page breakage
commit 15aaa819e20cb183f26392ed8ea16020630ef142 broke large page
handling.
With large pages it is valid to enter mmu_set_spte() with a gfn
different than what current shadow pte contains, when overwritting a PTE
page pointer.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 95c12bc..9cd75ee 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1047,25 +1047,24 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
*shadow_pte,
write_fault, user_fault, gfn);
if (is_rmap_pte(*shadow_pte)) {
- if (page != spte_to_page(*shadow_pte))
- rmap_remove(vcpu->kvm, shadow_pte);
- else
- was_rmapped = 1;
- }
-
- /*
-* If we overwrite a PTE page pointer with a 2MB PMD, unlink
-* the parent of the now unreachable PTE.
-*/
- if (largepage) {
- if (was_rmapped && !is_large_pte(*shadow_pte)) {
+ /*
+* If we overwrite a PTE page pointer with a 2MB PMD, unlink
+* the parent of the now unreachable PTE.
+*/
+ if (largepage && !is_large_pte(*shadow_pte)) {
struct kvm_mmu_page *child;
u64 pte = *shadow_pte;
child = page_header(pte & PT64_BASE_ADDR_MASK);
mmu_page_remove_parent_pte(child, shadow_pte);
+ } else if (page != spte_to_page(*shadow_pte))
+ rmap_remove(vcpu->kvm, shadow_pte);
+ else {
+ if (largepage)
+ was_rmapped = is_large_pte(*shadow_pte);
+ else
+ was_rmapped = 1;
}
- was_rmapped = is_large_pte(*shadow_pte);
}
/*
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/5] trivial fixes to silence compilation warnings
The following series contains unrelated patches with fixes to compilation warnings added since kvm-63; because of redefined macros, undefined functions or mismatched pointer types. PATCH 1/5 : libkvm: missing declaration for kvm_disable_pit_creation PATCH 2/5 : qemu: cpu_model is a constant string PATCH 3/5 : qemu: model in NICInfo is a constant string PATCH 4/5 : qemu: PCI_COMMAND_SERR redefined PATCH 5/5 : qemu: ARRAY_SIZE redefined Carlo - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/5] libkvm: export kvm_disable_pit_creation to support -no-kvm-pit
qemu/qemu-kvm.c: In function `kvm_qemu_create_context': qemu/qemu-kvm.c:549: warning: implicit declaration of function `kvm_disable_pit_creation' Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> --- libkvm/libkvm.h | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h index 61e7e98..29584d9 100644 --- a/libkvm/libkvm.h +++ b/libkvm/libkvm.h @@ -107,6 +107,16 @@ void kvm_finalize(kvm_context_t kvm); void kvm_disable_irqchip_creation(kvm_context_t kvm); /*! + * \brief Disable the in-kernel PIT creation + * + * In-kernel pit is enabled by default. If userspace pit is to be used, + * this should be called prior to kvm_create(). + * + * \param kvm Pointer to the kvm_context + */ +void kvm_disable_pit_creation(kvm_context_t kvm); + +/*! * \brief Create new virtual machine * * This creates a new virtual machine, maps physical RAM to it, and creates a -- 1.5.3.7 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/5] qemu: cpu_model is a pointer to a constant string
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 |5 ++---
qemu/sysemu.h |2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 2670642..a7e5e26 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -685,10 +685,9 @@ static void pciej_write(void *opaque, uint32_t addr,
uint32_t val)
#endif
}
+static const char *model;
-static 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 c728605..c60072d 100644
--- a/qemu/sysemu.h
+++ b/qemu/sysemu.h
@@ -175,7 +175,7 @@ extern int drive_init(struct drive_opt *arg, int snapshot,
void *machine);
/* 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);
void qemu_system_device_hot_add(int pcibus, int slot, int state);
/* device-hotplug */
--
1.5.3.7
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/5] qemu: model in NICInfo is a pointer to a constant string
qemu/vl.c: In function `net_client_uninit': qemu/vl.c:4951: warning: passing arg 1 of `free' discards qualifiers from pointer target type Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> --- qemu/vl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/qemu/vl.c b/qemu/vl.c index 3570388..3f6eca3 100644 --- a/qemu/vl.c +++ b/qemu/vl.c @@ -4944,7 +4944,7 @@ void net_client_uninit(NICInfo *nd) nd->vlan->nb_guest_devs--; /* XXX: free vlan on last reference */ nb_nics--; nd->used = 0; -free(nd->model); +free((void *)nd->model); } void do_info_network(void) -- 1.5.3.7 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] virtio-blk: allow more than one in-flight request
On Friday 28 March 2008 03:29:48 Marcelo Tosatti wrote: > Allow more than one in-flight request in the virtio ring. This allows > the host driver to submit requests in parallel. > > Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> For a moment, I thought this was true and felt very stupid :) For the record, the mempool_alloc becomes kmalloc with fallback to the pool. We only need one because we can make progress with one request at a time if we have to. Cheers, Rusty. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 4/5] qemu: PCI_COMMAND_SERR redefined from linux headers
qemu/hw/cirrus_vga.c:193:1: warning: "PCI_COMMAND_SERR" redefined In file included from /usr/include/linux/pci.h:21, from /var/tmp/portage/app-emulation/kvm-64/work/kvm-64/qemu/hw/pci.h:6, from /var/tmp/portage/app-emulation/kvm-64/work/kvm-64/qemu/hw/cirrus_vga.c:31: /usr/include/linux/pci_regs.h:40:1: warning: this is the location of the previous definition Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> --- qemu/hw/cirrus_vga.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c index e14ec35..86ed511 100644 --- a/qemu/hw/cirrus_vga.c +++ b/qemu/hw/cirrus_vga.c @@ -190,7 +190,7 @@ #define PCI_COMMAND_PALETTESNOOPING 0x0020 #define PCI_COMMAND_PARITYDETECTION 0x0040 #define PCI_COMMAND_ADDRESSDATASTEPPING 0x0080 -#define PCI_COMMAND_SERR0x0100 +#define PCI_COMMAND_SOFTERR 0x0100 #define PCI_COMMAND_BACKTOBACKTRANS 0x0200 // PCI 0x08, 0xff00 (0x09-0x0b:class,0x08:rev) #define PCI_CLASS_BASE_DISPLAY0x03 -- 1.5.3.7 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 5/5] qemu: ARRAY_SIZE redefined
qemu/qemu-kvm-x86.c:23:1: warning: "ARRAY_SIZE" redefined In file included from ../cpu-defs.h:30, from /var/tmp/portage/app-emulation/kvm-64/work/kvm-64/qemu/target-i386/cpu.h:45, from ../qemu-common.h:62, from /var/tmp/portage/app-emulation/kvm-64/work/kvm-64/qemu/hw/hw.h:5, from /var/tmp/portage/app-emulation/kvm-64/work/kvm-64/qemu/qemu-kvm-x86.c:13: ../osdep.h:30:1: warning: this is the location of the previous definition Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> --- qemu/qemu-kvm-x86.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/qemu/qemu-kvm-x86.c b/qemu/qemu-kvm-x86.c index 78490c5..ab91ff2 100644 --- a/qemu/qemu-kvm-x86.c +++ b/qemu/qemu-kvm-x86.c @@ -20,7 +20,9 @@ #define MSR_IA32_TSC 0x10 +#ifndef ARRAY_SIZE #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0])) +#endif static struct kvm_msr_list *kvm_msr_list; extern unsigned int kvm_shadow_memory; -- 1.5.3.7 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] 7-11 апреля, гостиница
Пpиглашаем Bаc пpинять yчаcтиве в тематичеckoм kypcе: Г o c т и н и ч н ы й б и з н е c: метoды эффеkтивнoгo yпpавления и метoды пpивлечения kлиентoв 07 - II апpеля, Cанkт-Петеpбypг B пpoгpамме: 1. Упpавленчеckая cтpykтypа coвpеменнoгo oтеля. 2. Ценoвая пoлитиkа гocтиницы и yпpавление дoхoдами. 3. Pocт и pазвитие пpедпpиятия. Cтpатегичеckий план pабoты пpедпpиятия. 4. Cтpатегия и таkтиkа пpивлечения и yдеpжания kлиентoв. 5. Пyти coздания пoзитивнoгo имиджа гocтиницы. 6. Poль маpkетинга и пpoдаж. Эффеkтивные пoдхoды k cocтавлению маpkетингoвoгo плана. 7. Маpkетинг cфеpы ycлyг гocтепpиимcтва. Оcнoвные фopмы pеkламы гocтиничных ycлyг. Междyнаpoдные cиcтемы бpoниpoвания нoмеpoв. 8. Пpoблема kачеcтва гocтиничных ycлyг. 9. Pазвития дoпoлнительных ycлyг: cмежный cеpвиc. 10. Pабoта c пеpcoналoм: внyтpенние cтандаpты oбcлyживания пpедпpиятия гocтиничнoгo бизнеcа. 11. Cпецифиkа yпpавления в cетевых oтелях. 12. Cпецифиkа pазвития и yпpавление мини-oтелями. 13. Пpавoвые аcпеkты деятельнocти пpедпpиятия cфеpы гocтиничнoгo бизнеcа. 14. Междyнаpoдная cиcтема cеpтифиkации гocтиниц. 15. Pазвитие гocтиничнoгo бизнеcа в pамkах oбщегopoдckoй пoлитиkи; yчаcтие в бизнеc-аccoциациях и coюзах kаk инcтpyмент влияния на pазвитие pынoчнoй cpеды. Пoлная пpoгpамма выcылаетcя пo запpocy. (812) 983 29 06 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] ignore reads to the EOI register.
On Wed, Mar 26, 2008 at 09:57:16PM -0300, Glauber Costa wrote: > They seem legal in real hardware, even though the EOI > is a write-only register. By "legal" I mean they are completely > ignored, but at least, don't cause any bits to be set at ESR. > > Without this patch, some (very recent) linux git trees will fail > to boot in i386. > > This is generated from kvm-userspace, but should apply well to > plain qemu too. > > Signed-off-by: Glauber Costa <[EMAIL PROTECTED]> > --- > qemu/hw/apic.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c > index 92248dd..4102493 100644 > --- a/qemu/hw/apic.c > +++ b/qemu/hw/apic.c > @@ -615,6 +615,8 @@ static uint32_t apic_mem_readl(void *opaque, > target_phys_addr_t addr) > /* ppr */ > val = apic_get_ppr(s); > break; > +case 0x0b: > +break; While I agree the guest should not care of the value (it should actually not read it), wouldn't it be safer to return a default value (0 ?) instead of an initialized value? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 0/2] separate thread for IO handling V2
- Fix reset, powerdown and shutdown. - Fix kvmctl. -- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 1/2] QEMU/KVM: separate thread for IO handling
Move IO processing from vcpu0 to a dedicated thread.
This removes load on vcpu0 by allowing better cache locality and also
improves latency.
We can now block signal handling for IO events, so sigtimedwait won't
race with handlers:
- Currently the SIGALRM handler fails to set CPU_INTERRUPT_EXIT because
the "next_cpu" variable is not initialized in the KVM path, meaning that
processing of timer expiration might be delayed until the next vcpu0 exit.
Index: kvm-userspace.io/qemu/qemu-kvm.c
===
--- kvm-userspace.io.orig/qemu/qemu-kvm.c
+++ kvm-userspace.io/qemu/qemu-kvm.c
@@ -28,6 +28,8 @@ kvm_context_t kvm_context;
extern int smp_cpus;
+static int qemu_kvm_reset_requested;
+
pthread_mutex_t qemu_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t qemu_aio_cond = PTHREAD_COND_INITIALIZER;
__thread struct vcpu_info *vcpu;
@@ -38,6 +40,7 @@ struct qemu_kvm_signal_table {
};
static struct qemu_kvm_signal_table io_signal_table;
+static struct qemu_kvm_signal_table vcpu_signal_table;
#define SIG_IPI (SIGRTMIN+4)
@@ -51,6 +54,8 @@ struct vcpu_info {
int stopped;
} vcpu_info[256];
+pthread_t io_thread;
+
static inline unsigned long kvm_get_thread_id(void)
{
return syscall(SYS_gettid);
@@ -67,12 +72,19 @@ static void sig_ipi_handler(int n)
void kvm_update_interrupt_request(CPUState *env)
{
-if (env && vcpu && env != vcpu->env) {
- if (vcpu_info[env->cpu_index].signalled)
- return;
- vcpu_info[env->cpu_index].signalled = 1;
- if (vcpu_info[env->cpu_index].thread)
- pthread_kill(vcpu_info[env->cpu_index].thread, SIG_IPI);
+int signal = 0;
+
+if (env) {
+if (!vcpu)
+signal = 1;
+if (vcpu && env != vcpu->env && !vcpu_info[env->cpu_index].signalled)
+signal = 1;
+
+if (signal) {
+vcpu_info[env->cpu_index].signalled = 1;
+if (vcpu_info[env->cpu_index].thread)
+pthread_kill(vcpu_info[env->cpu_index].thread, SIG_IPI);
+}
}
}
@@ -105,7 +117,7 @@ static void post_kvm_run(void *opaque, i
static int pre_kvm_run(void *opaque, int vcpu)
{
-CPUState *env = cpu_single_env;
+CPUState *env = qemu_kvm_cpu_env(vcpu);
kvm_arch_pre_kvm_run(opaque, vcpu);
@@ -151,7 +163,8 @@ static int has_work(CPUState *env)
return kvm_arch_has_work(env);
}
-static int kvm_eat_signal(CPUState *env, int timeout)
+static int kvm_eat_signal(struct qemu_kvm_signal_table *waitset, CPUState *env,
+ int timeout)
{
struct timespec ts;
int r, e, ret = 0;
@@ -160,12 +173,12 @@ static int kvm_eat_signal(CPUState *env,
ts.tv_sec = timeout / 1000;
ts.tv_nsec = (timeout % 1000) * 100;
-r = sigtimedwait(&io_signal_table.sigset, &siginfo, &ts);
+r = sigtimedwait(&waitset->sigset, &siginfo, &ts);
if (r == -1 && (errno == EAGAIN || errno == EINTR) && !timeout)
return 0;
e = errno;
pthread_mutex_lock(&qemu_mutex);
-if (vcpu)
+if (env && vcpu)
cpu_single_env = vcpu->env;
if (r == -1 && !(errno == EAGAIN || errno == EINTR)) {
printf("sigtimedwait: %s\n", strerror(e));
@@ -181,7 +194,7 @@ static int kvm_eat_signal(CPUState *env,
if (env && vcpu_info[env->cpu_index].stop) {
vcpu_info[env->cpu_index].stop = 0;
vcpu_info[env->cpu_index].stopped = 1;
- pthread_kill(vcpu_info[0].thread, SIG_IPI);
+ pthread_kill(io_thread, SIGUSR1);
}
pthread_mutex_unlock(&qemu_mutex);
@@ -192,24 +205,16 @@ static int kvm_eat_signal(CPUState *env,
static void kvm_eat_signals(CPUState *env, int timeout)
{
int r = 0;
+struct qemu_kvm_signal_table *waitset = &vcpu_signal_table;
-while (kvm_eat_signal(env, 0))
+while (kvm_eat_signal(waitset, env, 0))
r = 1;
if (!r && timeout) {
- r = kvm_eat_signal(env, timeout);
+ r = kvm_eat_signal(waitset, env, timeout);
if (r)
- while (kvm_eat_signal(env, 0))
+ while (kvm_eat_signal(waitset, env, 0))
;
}
-/*
- * we call select() even if no signal was received, to account for
- * for which there is no signal handler installed.
- */
-pthread_mutex_lock(&qemu_mutex);
-cpu_single_env = vcpu->env;
-if (env->cpu_index == 0)
- main_loop_wait(0);
-pthread_mutex_unlock(&qemu_mutex);
}
static void kvm_main_loop_wait(CPUState *env, int timeout)
@@ -225,29 +230,29 @@ static int all_threads_paused(void)
{
int i;
-for (i = 1; i < smp_cpus; ++i)
+for (i = 0; i < smp_cpus; ++i)
if (vcpu_info[i].stopped)
return 0;
return 1;
}
-static void pause_other_threads(void)
+static void pause_all_threads(void)
{
int i;
-for (i = 1; i < smp_cpus; ++i) {
+for (i = 0; i < smp_cpus; ++i) {
vcpu_info[i].stop = 1;
pthread_kill(vcpu_info[i].thread, S
[kvm-devel] [patch 2/2] QEMU/KVM: add function to handle signals
SIGUSR1 has no handler, and the SIGUSR2 one does nothing useful anymore
(thats also true for SIGIO on tap fd, which runs host_alarm_handler
unnecessarily).
Index: kvm-userspace.io/qemu/qemu-kvm.c
===
--- kvm-userspace.io.orig/qemu/qemu-kvm.c
+++ kvm-userspace.io/qemu/qemu-kvm.c
@@ -163,13 +163,30 @@ static int has_work(CPUState *env)
return kvm_arch_has_work(env);
}
+static int kvm_process_signal(int si_signo)
+{
+struct sigaction sa;
+
+switch (si_signo) {
+case SIGUSR2:
+pthread_cond_signal(&qemu_aio_cond);
+break;
+case SIGALRM:
+case SIGIO:
+sigaction(si_signo, NULL, &sa);
+sa.sa_handler(si_signo);
+break;
+}
+
+return 1;
+}
+
static int kvm_eat_signal(struct qemu_kvm_signal_table *waitset, CPUState *env,
int timeout)
{
struct timespec ts;
int r, e, ret = 0;
siginfo_t siginfo;
-struct sigaction sa;
ts.tv_sec = timeout / 1000;
ts.tv_nsec = (timeout % 1000) * 100;
@@ -184,13 +201,9 @@ static int kvm_eat_signal(struct qemu_kv
printf("sigtimedwait: %s\n", strerror(e));
exit(1);
}
-if (r != -1) {
- sigaction(siginfo.si_signo, NULL, &sa);
- sa.sa_handler(siginfo.si_signo);
- if (siginfo.si_signo == SIGUSR2)
- pthread_cond_signal(&qemu_aio_cond);
- ret = 1;
-}
+if (r != -1)
+ret = kvm_process_signal(siginfo.si_signo);
+
if (env && vcpu_info[env->cpu_index].stop) {
vcpu_info[env->cpu_index].stop = 0;
vcpu_info[env->cpu_index].stopped = 1;
--
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM: VMX: Enabling MSR Bitmap feature
From 560146a8f93fa61aa6e6a6cc78087e24da8b9693 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Fri, 28 Mar 2008 13:18:56 +0800
Subject: [PATCH] KVM: VMX: Enabling MSR Bitmap feature
MSR Bitmap can control if the accessing of MSR causing VM Exit.
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c | 67 ++-
1 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index cbca46a..87eee7a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -91,6 +91,7 @@ static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
static struct page *vmx_io_bitmap_a;
static struct page *vmx_io_bitmap_b;
+static struct page *vmx_msr_bitmap;
static DECLARE_BITMAP(vmx_vpid_bitmap, VMX_NR_VPIDS);
static DEFINE_SPINLOCK(vmx_vpid_lock);
@@ -185,6 +186,11 @@ static inline int is_external_interrupt(u32 intr_info)
== (INTR_TYPE_EXT_INTR | INTR_INFO_VALID_MASK);
}
+static inline int cpu_has_vmx_msr_bitmap(void)
+{
+ return (vmcs_config.cpu_based_exec_ctrl & CPU_BASED_USE_MSR_BITMAPS);
+}
+
static inline int cpu_has_vmx_tpr_shadow(void)
{
return (vmcs_config.cpu_based_exec_ctrl & CPU_BASED_TPR_SHADOW);
@@ -1001,6 +1007,7 @@ static __init int setup_vmcs_config(struct vmcs_config
*vmcs_conf)
CPU_BASED_MOV_DR_EXITING |
CPU_BASED_USE_TSC_OFFSETING;
opt = CPU_BASED_TPR_SHADOW |
+ CPU_BASED_USE_MSR_BITMAPS |
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
if (adjust_vmx_controls(min, opt, MSR_IA32_VMX_PROCBASED_CTLS,
&_cpu_based_exec_control) < 0)
@@ -1575,6 +1582,30 @@ static void allocate_vpid(struct vcpu_vmx *vmx)
spin_unlock(&vmx_vpid_lock);
}
+void vmx_disable_intercept_for_msr(struct page *msr_bitmap, u32 msr)
+{
+ void *va;
+
+ if (!cpu_has_vmx_msr_bitmap())
+ return;
+
+ /*
+* See Intel PRM Vol. 3, 20.6.9 (MSR-Bitmap Address). Early manuals
+* have the write-low and read-high bitmap offsets the wrong way round.
+* We can control MSRs 0x-0x1fff and 0xc000-0xc0001fff.
+*/
+ va = kmap(msr_bitmap);
+ if (msr <= 0x1fff) {
+ __clear_bit(msr, va + 0x000); /* read-low */
+ __clear_bit(msr, va + 0x800); /* write-low */
+ } else if ((msr >= 0xc000) && (msr <= 0xc0001fff)) {
+ msr &= 0x1fff;
+ __clear_bit(msr, va + 0x400); /* read-high */
+ __clear_bit(msr, va + 0xc00); /* write-high */
+ }
+ kunmap(msr_bitmap);
+}
+
/*
* Sets up the vmcs for emulated real mode.
*/
@@ -1592,6 +1623,9 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
vmcs_write64(IO_BITMAP_A, page_to_phys(vmx_io_bitmap_a));
vmcs_write64(IO_BITMAP_B, page_to_phys(vmx_io_bitmap_b));
+ if (cpu_has_vmx_msr_bitmap())
+ vmcs_write64(MSR_BITMAP, page_to_phys(vmx_msr_bitmap));
+
vmcs_write64(VMCS_LINK_POINTER, -1ull); /* 22.3.1.5 */
/* Control */
@@ -2728,7 +2762,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
static int __init vmx_init(void)
{
- void *iova;
+ void *va;
int r;
vmx_io_bitmap_a = alloc_page(GFP_KERNEL | __GFP_HIGHMEM);
@@ -2741,30 +2775,48 @@ static int __init vmx_init(void)
goto out;
}
+ vmx_msr_bitmap = alloc_page(GFP_KERNEL | __GFP_HIGHMEM);
+ if (!vmx_msr_bitmap) {
+ r = -ENOMEM;
+ goto out1;
+ }
+
/*
* Allow direct access to the PC debug port (it is often used for I/O
* delays, but the vmexits simply slow things down).
*/
- iova = kmap(vmx_io_bitmap_a);
- memset(iova, 0xff, PAGE_SIZE);
- clear_bit(0x80, iova);
+ va = kmap(vmx_io_bitmap_a);
+ memset(va, 0xff, PAGE_SIZE);
+ clear_bit(0x80, va);
kunmap(vmx_io_bitmap_a);
- iova = kmap(vmx_io_bitmap_b);
- memset(iova, 0xff, PAGE_SIZE);
+ va = kmap(vmx_io_bitmap_b);
+ memset(va, 0xff, PAGE_SIZE);
kunmap(vmx_io_bitmap_b);
+ va = kmap(vmx_msr_bitmap);
+ memset(va, 0xff, PAGE_SIZE);
+ kunmap(vmx_msr_bitmap);
+
set_bit(0, vmx_vpid_bitmap); /* 0 is reserved for host */
r = kvm_init(&vmx_x86_ops, sizeof(struct vcpu_vmx), THIS_MODULE);
if (r)
- goto out1;
+ goto out2;
+
+ vmx_disable_intercept_for_msr(vmx_msr_bitmap, MSR_FS_BASE);
+ vmx_disable_intercept_for_msr(vmx_msr_bitmap, MSR_GS_BASE);
+ vmx_disable_intercept_for_msr(vmx_msr_bitmap, MSR_IA32_SYSENTER_CS);
+ vmx_disable_intercept_for_msr(vmx_msr_bitmap, MSR_IA32_SYSENTER_ESP);
+ vmx_disable_intercept_for_msr(vmx_msr_bitmap, MSR_IA32_SYSENTER_EIP);
if (bypass_guest_pf)
kvm_mmu_set_nonpresent_ptes(~0xffeull, 0ull);
return
