Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Christian Ehrhardt wrote: Hi Xiantao, it looks good to me to move kvm_vcpu_cache out to the x86 specific code Why is that? Do other archs not want kvm_vcpu_cache, or is it just the alignment? At lease we didn't fall across the similar requirements about such alignment issues in IA64. What I mean is, other archs do require kvm_vcpu_cache (without the alignment), so why move the code? Just make the alignment arch dependent with a #define. I think IA64 TOTALLY doen't need this logic, so do the move:) Ah, I see. It isn't just the alignment. How do you allocate kvm_vcpu, then? What about s390 and powerpc? I imagine they don't have an alignment issue, but do they have a totally unique way of allocating vcpus as well? Maybe we should just #ifndef CONFIG_IA64 (or #ifdef CONFIG_HAVE_SPECIAL_VCPU_ALLOC) this bit instead of duplicating it for s390 and ppc. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Avi Kivity wrote:
Zhang, Xiantao wrote:
Avi Kivity wrote:
Christian Ehrhardt wrote:
Hi Xiantao,
it looks good to me to move kvm_vcpu_cache out to the x86 specific
code
Why is that? Do other archs not want kvm_vcpu_cache, or is it just
the alignment?
At lease we didn't fall across the similar requirements about such
alignment issues in IA64.
What I mean is, other archs do require kvm_vcpu_cache (without the
alignment), so why move the code? Just make the alignment arch
dependent with a #define.
I think IA64 TOTALLY doen't need this logic, so do the move:)
Oh, and since the code is written as
-/* A kmem cache lets us meet the alignment requirements of
fx_save. */
-kvm_vcpu_cache = kmem_cache_create(kvm_vcpu, vcpu_size,
- __alignof__(struct kvm_vcpu),
- 0, NULL);
-if (!kvm_vcpu_cache) {
If other archs don't require special alignment for kvm_vcpu,
__alignof__(struct kvm_vcpu) will return the natural alignment for
that arch, and no memory will be wasted.
We use a very different method to allocate kvm_vcpu memory in IA64
side.
So we have to set vcpu_size to zero. But if vcpu_size is set to zero,
kmem_cache_create returns error, and this logic can't handle this error.
Finally, make the kvm_init aborted. Otherwise, it wastes memory.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 3] create kvm_x86
Avi Kivity wrote:
Hollis Blanchard wrote:
On Wed, 2007-11-21 at 11:18 +0200, Avi Kivity wrote:
Well, I hate to say it, but the resulting code doesn't look too well
(all the kvm_x86 variables), and it's entirely my fault as I
recommended this approach. Not like it was difficult to predict.
I guess we still have reached no conclusion on this question?
Right. Thanks for re-raising it.
Thanks too. I have almost done the rebase work for IA64 support, maybe
we should work out a solution for that :)
I'm thinking again of
struct kvm {
struct kvm_arch a;
...
}
Where each arch defines its own kvm_arch. Now the changes look
like a bunch of kvm-blah to kvm-a.blah conversions.
The nicer one:
struct kvm {
struct kvm_arch arch;
// common fields
}
I prefer this one, seems it is more direct and readable. Same thinking
about kvm_vcpu structure:)
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Zhang, Xiantao wrote:
Avi Kivity wrote:
Christian Ehrhardt wrote:
Hi Xiantao,
it looks good to me to move kvm_vcpu_cache out to the x86 specific
code
Why is that? Do other archs not want kvm_vcpu_cache, or is it just
the alignment?
At lease we didn't fall across the similar requirements about such
alignment issues in IA64.
What I mean is, other archs do require kvm_vcpu_cache (without the
alignment), so why move the code? Just make the alignment arch
dependent with a #define.
Oh, and since the code is written as
- /* A kmem cache lets us meet the alignment requirements of
fx_save. */
- kvm_vcpu_cache = kmem_cache_create(kvm_vcpu, vcpu_size,
-__alignof__(struct kvm_vcpu),
-0, NULL);
- if (!kvm_vcpu_cache) {
If other archs don't require special alignment for kvm_vcpu,
__alignof__(struct kvm_vcpu) will return the natural alignment for that
arch, and no memory will be wasted.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Avi Kivity wrote: Christian Ehrhardt wrote: Hi Xiantao, it looks good to me to move kvm_vcpu_cache out to the x86 specific code Why is that? Do other archs not want kvm_vcpu_cache, or is it just the alignment? At lease we didn't fall across the similar requirements about such alignment issues in IA64. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Eliminate the difference of ioapic andiosapic
Avi Kivity wrote: Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 29 Nov 2007 18:17:13 +0800 Subject: [PATCH] Clearing up the difference of ioapic and iosapic Since IA64 uses iosapic, we want to merget it with current ioapic code. This patch should make x86 and IA64 happy. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] --- drivers/kvm/ioapic.c | 26 +- drivers/kvm/irq.h|5 +++-- drivers/kvm/lapic.c | 23 ++- 3 files changed, 34 insertions(+), 20 deletions(-) diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c index cf1d50b..79c48ec 100644 --- a/drivers/kvm/ioapic.c +++ b/drivers/kvm/ioapic.c @@ -36,11 +36,8 @@ #include asm/page.h #include asm/current.h -#include asm/apicdef.h -#include asm/io_apic.h This will break compilation under certain .configs. Other than that, the patch is good. Can we use the compile option CONFIG_X86 to handle it ? Xiantao - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ kvm-Bugs-1840186 ] KVM configure script doesn't checks for unifdef
Dan Kenigsberg wrote: On Wed, Nov 28, 2007 at 03:06:52AM -0800, SourceForge.net wrote: Bugs item #1840186, was opened at 2007-11-28 13:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1840186group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: KVM configure script doesn't checks for unifdef Initial Comment: Without unifdef package installed, KVM-54 refuses to compile from GIT on Fedora 7. Compilation works fine from .tar.gz. It is used by make sync command, but I believe that a user deserves to get a human-readable error. Either make or configure command must be fixed to handle such situations. How about adding diff --git a/kernel/Makefile b/kernel/Makefile index 22326b2..90930b2 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -31,6 +31,7 @@ sync: rsync $(LINUX)/include/asm-x86/kvm_para.h include/asm rsync $(LINUX)/include/asm-x86/kvm.h include/asm + type unifdef /dev/null 21 || echo sync requires unifdef false $(call unifdef, include/linux/kvm.h) $(call unifdef, include/linux/kvm_para.h) $(call unifdef, include/asm/kvm.h) ? kvm.git's make already handles this. P.S., why does a failed $(call) does not stop make as any other failed step? Is it a feature of 'make'? In general it does, but unifdef needs special handling since it returns 1 when all is fine (thanks unifdef developers). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 2] Add small pieces for userspace powerpc support
Jerone Young wrote: These patches add two things: libkvm skelton support powerpc tests (but missing kvmctl main.c) Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm54 hang on amd3000
JiSheng Zhang wrote: once start kvm, the host machine hang cpu:AMD Athlon(tm) 64 Processor 3000+ kvm:kvm54 host kernel version:2.6.23 host kernel arch:i386 guest:linux 32bit 2.6.23 command to start kvm:qemu-system-x86_64 -hda linux.img the problem does not appear with the -no-kvm switch Are you certain you are using the modules from kvm-54, or the modules from 2.6.23? 2.6.23 has a problem on AMD. I will send patches for 2.6.23.10 shortly. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Avi Kivity wrote: Zhang, Xiantao wrote: Ah, I see. It isn't just the alignment. How do you allocate kvm_vcpu, then? For evevy vm, we allocate a big chunk of memory for structure allocation. For vcpu, it should be always 64k aligned through our allocation mechanism. So, we don't care about its aligment issue :) I see. Can you explain why you do that? Do you have a special allocator in your guest-resident vmm module? Since our VMM module and KVM module will share the kvm and vcpu structure, but VMM module has a different address space, so we have to use fixed allocation method to handle this share. For example, we allocates 1M memory(1M align) for every vm for this purpose in kvm module, and the first 64k is used for first vcpu of guest, and the second 64 for the second vcpu, and same for other vcpus. You can call it as special allocator or other names:) This is determined by IA64 virtualization architecture, and hard to workaround it in this host-based vm model. :( Xiantao I don't think other archs need that, so a CONFIG_KVM_ARCH_CVPU_ALLOC approach seems better than copying all that code. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Move x86 ioctl definitions from include/linux/kvm.h
Jerone Young wrote: This patch is a continuation of the 7 patches sent earlier. This patch moves all x86 specific macros from include/linux/kvm.h to include/asm-x86/kvm.h. Just noticed I'd dropped this old patch. Unfortunately kvm.git has changed in this area. Care to re-spin? Sorry about the drop. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 3] create kvm_x86
Hollis Blanchard wrote:
On Fri, 2007-11-30 at 11:04 +0200, Avi Kivity wrote:
Zhang, Xiantao wrote:
The nicer one:
struct kvm {
struct kvm_arch arch;
// common fields
}
I prefer this one, seems it is more direct and readable. Same thinking
about kvm_vcpu structure:)
I agree, kvm_vcpu should use the same method.
And we will convert vcpu_vmx/vcpu_svm as well?
These cannot use the same method, since we need to support both vmx and
svm in the same binary. The arch specific members aren't the same size,
nor do the symbols they use have the same visibility.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] How to handle kvm-abi-10 case for other archs.
Hi, Avi I think new archs for kvm doesn't need to care about kvm-abi case in their code, since current abi is bigger than 10. But in current libkvm.c, we can see that many abi-specific code in it. How to handle it ? Can we use __x86__ macro to make it sightless for other archs or other good methods ? Thanks Xiantao - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Fwd: kvm54 hang on amd3000
-- Forwarded message -- From: JiSheng Zhang [EMAIL PROTECTED] Date: 2007-12-1 上午10:54 Subject: Re: [kvm-devel] kvm54 hang on amd3000 To: Avi Kivity [EMAIL PROTECTED] Hi Avi, 2007/11/30, Avi Kivity [EMAIL PROTECTED]: JiSheng Zhang wrote: once start kvm, the host machine hang cpu:AMD Athlon(tm) 64 Processor 3000+ kvm:kvm54 host kernel version:2.6.23 host kernel arch:i386 guest:linux 32bit 2.6.23 command to start kvm:qemu-system-x86_64 -hda linux.img the problem does not appear with the -no-kvm switch Are you certain you are using the modules from kvm-54, or the modules from 2.6.23? 2.6.23 has a problem on AMD. I will send patches for 2.6.23.10 shortly. Got it, the reason is that I used the modules from current stable mainline kernel 2.6.23.9. ^_^. Thanks, JiSheng -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1842160 ] Solaris 10 8/07 (AKA update 4) x86 guest can't boot 64 bit
Bugs item #1842160, was opened at 2007-11-30 21:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1842160group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carlo Marcelo Arenas Belon (carenas) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 10 8/07 (AKA update 4) x86 guest can't boot 64 bit Initial Comment: Host CPU: Intel(R) Core(TM)2 CPU 6320 KVM: 54 + ide patches and set_cr3 patch pre-kvm-55 Host OS: Gentoo 2007.0 with kernel 2.6.22-gentoo-r9 Host ARCH: amd64 (64bit) Guest OS: Solaris 10 8/07 x86 Generic 120012-14 VM parameters: -m 512 problem only happens when running kvm's CPU emulation (doesn't happen with -no-kvm) and triggers a GP as shown by : set_cr4: #GP, clearing PAE while in long mode inject_general_protection: rip 0x100ee24. it might be related to the GP reported as part of the discussion for bug 1699695 which apparently has a patch available (but not yet committed) which I hadn't been able to track down to test -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1842160group_id=180599 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 3] create kvm_x86
On Fri, 2007-11-30 at 15:43 -0600, Anthony Liguori wrote: Hollis Blanchard wrote: On Fri, 2007-11-30 at 22:31 +0200, Avi Kivity wrote: These cannot use the same method, since we need to support both vmx and svm in the same binary. The arch specific members aren't the same size, nor do the symbols they use have the same visibility. I have never understood this. Why on earth do you need to support VMX and SVM in the same binary? For example, when would you overwrite kvm_x86_ops after initialization? If you wouldn't, then why are you using function pointers instead of the linker? It's necessary for the distros to be able to ship both AMD and Intel support in a single binary. We aren't talking, in general, about a single static binary but instead loadable modules. There maybe some cases where it's useful to support both in a static kernel binary. I think the monolithic case is the one I overlooked. As long as everything is a module, there should be no problem loading the appropriate module for the host processor type. However, once you want to support both processor types in a monolithic kernel, that's where you need the function pointer flexibility. If you used the linker instead of function pointers, it would be impossible to build a static kernel binary that supported both. Plus, depmod would get very confused because two modules would be providing the same symbols. It can be made to work, but it's kind of funky. PowerPC will also need to support multiple processor types, and so I expect to have one kvm_arch structure for each. That also means struct kvm_arch must be the *last* member in struct kvm, which is not how it is shown above. Instead of having a kvm.ko and a kvm-ppc-440.ko, you probably should have a kvm.ko and a kvm-ppc.ko and then build the kvm-ppc.ko based on the board. You would never build multiple kvm-ppc-XXX.ko modules in the same binary right? I hope to have multiple kvm-ppc-XXX.ko modules loaded simultaneously to support different guest types on the same host. I haven't yet figured out what that interface should look like, but obviously linking is preferable to function pointers where feasible. -- Hollis Blanchard IBM Linux Technology Center - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 3] create kvm_x86
On Fri, 2007-11-30 at 22:31 +0200, Avi Kivity wrote:
Hollis Blanchard wrote:
On Fri, 2007-11-30 at 11:04 +0200, Avi Kivity wrote:
Zhang, Xiantao wrote:
The nicer one:
struct kvm {
struct kvm_arch arch;
// common fields
}
I prefer this one, seems it is more direct and readable. Same thinking
about kvm_vcpu structure:)
I agree, kvm_vcpu should use the same method.
And we will convert vcpu_vmx/vcpu_svm as well?
These cannot use the same method, since we need to support both vmx and
svm in the same binary. The arch specific members aren't the same size,
nor do the symbols they use have the same visibility.
I have never understood this. Why on earth do you need to support VMX
and SVM in the same binary? For example, when would you overwrite
kvm_x86_ops after initialization? If you wouldn't, then why are you
using function pointers instead of the linker?
PowerPC will also need to support multiple processor types, and so I
expect to have one kvm_arch structure for each. That also means struct
kvm_arch must be the *last* member in struct kvm, which is not how it is
shown above.
--
Hollis Blanchard
IBM Linux Technology Center
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 3] create kvm_x86
Hollis Blanchard wrote:
On Fri, 2007-11-30 at 22:31 +0200, Avi Kivity wrote:
Hollis Blanchard wrote:
On Fri, 2007-11-30 at 11:04 +0200, Avi Kivity wrote:
Zhang, Xiantao wrote:
The nicer one:
struct kvm {
struct kvm_arch arch;
// common fields
}
I prefer this one, seems it is more direct and readable. Same thinking
about kvm_vcpu structure:)
I agree, kvm_vcpu should use the same method.
And we will convert vcpu_vmx/vcpu_svm as well?
These cannot use the same method, since we need to support both vmx and
svm in the same binary. The arch specific members aren't the same size,
nor do the symbols they use have the same visibility.
I have never understood this. Why on earth do you need to support VMX
and SVM in the same binary? For example, when would you overwrite
kvm_x86_ops after initialization? If you wouldn't, then why are you
using function pointers instead of the linker?
It's necessary for the distros to be able to ship both AMD and Intel
support in a single binary. We aren't talking, in general, about a
single static binary but instead loadable modules. There maybe some
cases where it's useful to support both in a static kernel binary.
If you used the linker instead of function pointers, it would be
impossible to build a static kernel binary that supported both. Plus,
depmod would get very confused because two modules would be providing
the same symbols. It can be made to work, but it's kind of funky.
PowerPC will also need to support multiple processor types, and so I
expect to have one kvm_arch structure for each. That also means struct
kvm_arch must be the *last* member in struct kvm, which is not how it is
shown above.
Instead of having a kvm.ko and a kvm-ppc-440.ko, you probably should
have a kvm.ko and a kvm-ppc.ko and then build the kvm-ppc.ko based on
the board. You would never build multiple kvm-ppc-XXX.ko modules in the
same binary right?
Regards,
Anthony Liguori
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel ff3784. .. , userspace 3a3429...
Hello, I have a few different Intel and AMD architectures where I could run automated tests like these. Is there any possibility of downloading a shared test-suite (disk images + automated scripts) for people like me (newbies wanting to contribute, at least with our spare CPU cycles) to be able to send equivalent reports on other architectures on the mailing list? I think it could be a great contribution for people having different architecture/hardware to be able to send at least partial test-suite results on every release, thus permitting developers to know the exact setup and OS version (same test-suite). It might help identify architecture specific, kernel specific or general issues on every kvm version (and keep the supported guests/hosts wiki page up-to-date with the last working version for a specific OS). If there are licenses issues with Windows images, we could have a small script (or a howto) for setting up a similar test suite with our own licenses and Windows CDs! Thanks, François. Zhao, Yunfeng wrote: -Original Message- From: Zhao, Yunfeng Sent: 2007年11月23日 16:46 To: kvm-devel Subject: KVM Test result, kernel 51727a1.. , userspace 6a385c9.. Hi, all, This is today's KVM test result against kvm.git ff378422888a8b3ff296e30297fcabf1c831ff83 and kvm-userspace.git 3a342937ce00c27b3eefd55032f261403b7ab5ab. One new issue: 1. Crashme causes RHEL5 guest kernel panic https://sourceforge.net/tracker/?func=detailatid=893831aid=1840711group_id=180599 Old issues: 2. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detailatid=893831aid=1826080group_id=180599 3. Cannot install 64bit vista guests. https://sourceforge.net/tracker/?func=detailatid=893831aid=1836905group_id=180599 4. Fails to save/restore guests https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_id=180599atid=893831 5. xp and win2k3 guest crashes https://sourceforge.net/tracker/?func=detailatid=893831aid=1819768group_id=180599 6. xpsp2 with 2vpus may fail to boot https://sourceforge.net/tracker/index.php?func=detailaid=1805017group_id=180599atid=893831 7. Cannot boot 32bit smp RHEL5.1 guest on 64bit host https://sourceforge.net/tracker/?func=detailatid=893831aid=1812043group_id=180599 Test environment Platformwoodcrest CPU 4 Memory size 8G' Details PAE: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallel PASS 4. boot linux and windows guest in parallel PASS 5. boot 4G linux guest PASS 6. boot guest with 1500M memory PASS 7. boot windows 2003 with ACPI enabled PASS 8. boot Windows xp with ACPI enabled PASS 9. boot Windows 2000 without ACPI PASS 10. kernel build on SMP linux guest PASS 11. LTP on SMP linux guest PASS 12. boot base kernel linux PASS 13. save/restore 32-bit HVM guestsFAIL 14. live migration 32-bit HVM guests FAIL 15. boot SMP Windows xp with ACPI enabled FAIL 16. boot SMP windows 2003 with ACPI enabled FAIL 17. boot SMP Windows 2000 with ACPI enabled FAIL IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallelPASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests FAIL 13. save/restore 32-bit linux guests FAIL 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32bit SMP Windows 2000 with ACPI enabled FAIL 16. boot 32-bit SMP Windows xp with ACPI enabled FAIL 17. boot 32-bit Windows 2000 without ACPI PASS 18. boot 64-bit Windows xp with ACPI enabled
Re: [kvm-devel] [PATCH] Move x86 ioctl definitions from include/linux/kvm.h
Actually this is was probably way overkill on moving these. I don't think that this patch is really needed. So I say just leave it be. Since they are macros they really cause no harm being where they are. It's also easier to make sure that none collide on the numbers they use. On Fri, 2007-11-30 at 11:49 +0200, Avi Kivity wrote: Jerone Young wrote: This patch is a continuation of the 7 patches sent earlier. This patch moves all x86 specific macros from include/linux/kvm.h to include/asm-x86/kvm.h. Just noticed I'd dropped this old patch. Unfortunately kvm.git has changed in this area. Care to re-spin? Sorry about the drop. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 3] create kvm_x86
On Fri, 2007-11-30 at 11:04 +0200, Avi Kivity wrote:
Zhang, Xiantao wrote:
The nicer one:
struct kvm {
struct kvm_arch arch;
// common fields
}
I prefer this one, seems it is more direct and readable. Same thinking
about kvm_vcpu structure:)
I agree, kvm_vcpu should use the same method.
And we will convert vcpu_vmx/vcpu_svm as well?
--
Hollis Blanchard
IBM Linux Technology Center
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
On Fri, 2007-11-30 at 16:50 +0200, Avi Kivity wrote: Carsten Otte wrote: Avi Kivity wrote: But you do need the vcpu cache, right? I think about organizing our SIE control blocks in it, just like vmx and svm do with their hardware structures backing a vcpu state. They're 512 bytes in size, and need to start on a 512-byte boundary. Sorry about my previous answer, I was confused by vcpu_cache / vcpu_decache for x86. It's friday... Ah, so you even need the alignment (which happen to be exactly the x86 fpu alignment). So we have two archs needing special allocation, and two archs using a common allocator. I think it's clear that this is an area that is likely to be very architecture-specific, and I don't think that duplicating kmem_cache_create() for each architecture is a big deal at all. In fact the x86 split today is already pretty weird, since the code that actually *uses* the cache (and the only code that knows what size the vcpu actually is!), isn't the code creating it. -- Hollis Blanchard IBM Linux Technology Center - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
On Fri, 2007-11-30 at 18:03 +0800, Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Ah, I see. It isn't just the alignment. How do you allocate kvm_vcpu, then? For evevy vm, we allocate a big chunk of memory for structure allocation. For vcpu, it should be always 64k aligned through our allocation mechanism. So, we don't care about its aligment issue :) I see. Can you explain why you do that? Do you have a special allocator in your guest-resident vmm module? Since our VMM module and KVM module will share the kvm and vcpu structure, but VMM module has a different address space, so we have to use fixed allocation method to handle this share. For example, we allocates 1M memory(1M align) for every vm for this purpose in kvm module, and the first 64k is used for first vcpu of guest, and the second 64 for the second vcpu, and same for other vcpus. You can call it as special allocator or other names:) This is determined by IA64 virtualization architecture, and hard to workaround it in this host-based vm model. :( We're doing something similar with very large allocations. Currently, PowerPC's vcpu is actually a copy of the exception handlers, plus the real vcpu data structure at a higher offset. Since our exception handlers can't span 64KB regions, we allocate a full 64KB for each vcpu. I'm not sure what benefit a kmem_cache would have in this situation... -- Hollis Blanchard IBM Linux Technology Center - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/5] qemu: IDE/ATAPI emulation reliability fixes
Carlo Marcelo Arenas Belon wrote: for qemu is probably not that much of a priority as they already have the patches, most of them committed and the bugs are only in their development tree which they don't release anyway, for kvm it is IMHO different since the bugs are on released code with patch 2 (which ate 3 of my FreeBSD guests with unrecoverable images which wouldn't even have a valid partition table) being around since the qemu import of Oct 1 and therefore part of kvm-45 and all releases up to the date. I understand though why you wouldn't like to divert from qemu, and I'll do my best to try to get qemu to commit those patches so that any future conflicts are resolved automatically, but as I said before, qemu just had different priorities. You make some good points; I'll respin the merge and this time bisect the problems and revert the offending patches. I'll add these patches as well if qemu hasn't merged it by that time. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Avi Kivity wrote: But you do need the vcpu cache, right? I think about organizing our SIE control blocks in it, just like vmx and svm do with their hardware structures backing a vcpu state. They're 512 bytes in size, and need to start on a 512-byte boundary. Sorry about my previous answer, I was confused by vcpu_cache / vcpu_decache for x86. It's friday... - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Carsten Otte wrote: Avi Kivity wrote: Why is that? Do other archs not want kvm_vcpu_cache, or is it just the alignment? On s390, our nice colleagues in the hardware depeartment take care of caching vcpu related data on a phyical one. No need to do anything for us in that area, except enjoying the benefits. This time, we don't even have to call an instruction for that :-). But you do need the vcpu cache, right? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Zhang, Xiantao wrote: Ah, I see. It isn't just the alignment. How do you allocate kvm_vcpu, then? For evevy vm, we allocate a big chunk of memory for structure allocation. For vcpu, it should be always 64k aligned through our allocation mechanism. So, we don't care about its aligment issue :) I see. Can you explain why you do that? Do you have a special allocator in your guest-resident vmm module? I don't think other archs need that, so a CONFIG_KVM_ARCH_CVPU_ALLOC approach seems better than copying all that code. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Eliminate the difference of ioapic andiosapic
Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 29 Nov 2007 18:17:13 +0800 Subject: [PATCH] Clearing up the difference of ioapic and iosapic Since IA64 uses iosapic, we want to merget it with current ioapic code. This patch should make x86 and IA64 happy. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] --- drivers/kvm/ioapic.c | 26 +- drivers/kvm/irq.h|5 +++-- drivers/kvm/lapic.c | 23 ++- 3 files changed, 34 insertions(+), 20 deletions(-) diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c index cf1d50b..79c48ec 100644 --- a/drivers/kvm/ioapic.c +++ b/drivers/kvm/ioapic.c @@ -36,11 +36,8 @@ #include asm/page.h #include asm/current.h -#include asm/apicdef.h -#include asm/io_apic.h This will break compilation under certain .configs. Other than that, the patch is good. Can we use the compile option CONFIG_X86 to handle it ? Xiantao Sure. But where does ia64 get its ioapic defines then? Things like dest_Fixed, I grepped for them in include/asm-ia64 but didn't find them. Maybe an include/asm-ia64/io_apic.h can provide them? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Christian Ehrhardt wrote: Hi Xiantao, it looks good to me to move kvm_vcpu_cache out to the x86 specific code Why is that? Do other archs not want kvm_vcpu_cache, or is it just the alignment? At lease we didn't fall across the similar requirements about such alignment issues in IA64. What I mean is, other archs do require kvm_vcpu_cache (without the alignment), so why move the code? Just make the alignment arch dependent with a #define. I think IA64 TOTALLY doen't need this logic, so do the move:) Ah, I see. It isn't just the alignment. How do you allocate kvm_vcpu, then? For evevy vm, we allocate a big chunk of memory for structure allocation. For vcpu, it should be always 64k aligned through our allocation mechanism. So, we don't care about its aligment issue :) What about s390 and powerpc? I imagine they don't have an alignment issue, but do they have a totally unique way of allocating vcpus as well? Maybe we should just #ifndef CONFIG_IA64 (or #ifdef CONFIG_HAVE_SPECIAL_VCPU_ALLOC) this bit instead of duplicating it for s390 and ppc. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Move CONFIG_X86 decleration to be x86 specific in configure script
Jerone Young wrote: # HG changeset patch # User Jerone Young [EMAIL PROTECTED] # Date 1196356414 21600 # Node ID 6fa44248cb3ad7b8a75ea7c23ee935103547fee4 # Parent eb2a8d4d818eb0b27feec303e028bd9944a28694 Move CONFIG_X86 decleration to be x86 specific in configure script In the configure script CONFIG_X86 is explicitly declared for qemu. Now while today the support for other archs is not exactly in kvm just yet (it's coming)..this shouldn't be specified for everyone ;-) Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Carsten Otte wrote: Avi Kivity wrote: But you do need the vcpu cache, right? I think about organizing our SIE control blocks in it, just like vmx and svm do with their hardware structures backing a vcpu state. They're 512 bytes in size, and need to start on a 512-byte boundary. Sorry about my previous answer, I was confused by vcpu_cache / vcpu_decache for x86. It's friday... Ah, so you even need the alignment (which happen to be exactly the x86 fpu alignment). So we have two archs needing special allocation, and two archs using a common allocator. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1841658 ] OpenSolaris 64bit panic with kvm-54
Bugs item #1841658, was opened at 2007-11-30 04:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1841658group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carlo Marcelo Arenas Belon (carenas) Assigned to: Nobody/Anonymous (nobody) Summary: OpenSolaris 64bit panic with kvm-54 Initial Comment: Wouldn't mark it as a regression per-se as vanilla kvm-53 wouldn't work (because of the need for IDE patches to get it to run/install), but vanilla kvm-54 or kvm-54 + the same patches added to kvm-53 and including pre-kvm-55 patches like 71be592a14aa8d127315b2c47bf83cc0d810a341 wouldn't work. The panic is observed in kvm-54 (--no-kvm runs ok, and --no-kvm-irqchip doesn't help) while running nexenta OpenSolaris alpha 7 or beta 1 (other OpenSolaris distributions most likely affected as well) and with the following trace : panic[cpu0]/thread=fffec2de2260: BAD TRAP: type=e (#pf Page fault) rp=ff0001735f30 addr=0 occurred in module unix due to a NULL pointer dereference dbus: #pf Page fault Bad kernel fault at addr=0x0 pid=278, pc=0xfb83c189, sp=0xff0001736028, eflags=0x10246 cr0: 80050033pg,wp,ne,et,mp,pe cr4: 6b8xmme,fxsr,pge,pae,pse,de cr2: 0 cr3: 7dc4000 cr8: 0 rdi:0 rsi: fffec0025630 rdx: fffec2de2260 rcx:1 r8: fffec0025630 r9:3 rax:0 rbx:0 rbp: ff0001736080 r10:1 r11: fffec1ad31e0 r12:0 r13: fffec0025680 r14: c0025488 r15:0 fsb:0 gsb: fbc26ef0 ds: 4b es: 4b fs:0 gs: 1c3 trp:e err:0 rip: fb83c189 cs: 30 rfl:10246 rsp: ff0001736028 ss: 38 ff0001735e10 unix:die+c8 () ff0001735f20 unix:trap+135b () ff0001735f30 unix:cmntrap+e9 () ff0001736080 unix:mutex_exit+9 () ff00017360c0 genunix:kmem_alloc+88 () ff0001736110 zfs:zio_push_transform+3a () ff0001736190 zfs:zio_create+256 () ff0001736240 zfs:zio_vdev_child_io+97 () ff0001736320 zfs:vdev_cache_read+182 () ff0001736370 zfs:vdev_disk_io_start+41 () ff0001736390 zfs:vdev_io_start+1d () ff00017363d0 zfs:zio_vdev_io_start+123 () ff00017363f0 zfs:zio_next_stage_async+bb () ff0001736410 zfs:zio_nowait+11 () ff0001736450 zfs:vdev_mirror_io_start+18f () ff0001736490 zfs:zio_vdev_io_start+131 () ff00017364b0 zfs:zio_next_stage+b3 () ff00017364e0 zfs:zio_ready+10e () ff0001736500 zfs:zio_next_stage+b3 () ff0001736550 zfs:zio_wait_for_children+5d () ff0001736570 zfs:zio_wait_children_ready+20 () ff0001736590 zfs:zio_next_stage_async+bb () ff00017365b0 zfs:zio_nowait+11 () ff0001736660 zfs:arc_read+4e8 () ff0001736700 zfs:dbuf_read_impl+129 () ff0001736760 zfs:dbuf_read+c5 () ff0001736810 zfs:dmu_buf_hold_array_by_dnode+1c4 () ff00017368a0 zfs:dmu_buf_hold_array+74 () ff0001736930 zfs:dmu_read_uio+4d () ff00017369c0 zfs:zfs_read+15e () ff0001736a30 genunix:fop_read+69 () ff0001736af0 genunix:vn_rdwr+161 () ff0001736c70 genunix:gexec+11c () ff0001736e90 genunix:exec_common+41d () ff0001736ec0 genunix:exece+1b () ff0001736f10 unix:brand_sys_sysenter+1f2 () while running in a Gentoo Linux 2007.0 host with Intel(R) Core(TM)2 CPU 6320. 32bit OpenSolaris works fine -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1841658group_id=180599 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 3] create kvm_x86
Avi Kivity wrote:
Zhang, Xiantao wrote:
The nicer one:
struct kvm {
struct kvm_arch arch;
// common fields
}
I prefer this one, seems it is more direct and readable. Same
thinking about kvm_vcpu structure:)
I agree, kvm_vcpu should use the same method.
OK, I will rebase the kvm structure split patches according to this
method. :-)
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Avi Kivity wrote: Why is that? Do other archs not want kvm_vcpu_cache, or is it just the alignment? On s390, our nice colleagues in the hardware depeartment take care of caching vcpu related data on a phyical one. No need to do anything for us in that area, except enjoying the benefits. This time, we don't even have to call an instruction for that :-). - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] dnsmasq and kvm question
jack snodgrass wrote: First of all... is there a 'newbie' list? I don't want to send stupid questions to the wrong list It's quite okay to send newbie questions here... is there a way to customize dnsmasq using a dnsmasq.conf file? This may be more Fedora 8 / libvirt / kvm related than kvm specific when libvirt and my kvm guest are started, dnsmasq is started automatically. It's does not use the /etc/dnsmasq.conf file and dnsmasq is not started from the /etc/rc.d/init.d/dnsmasq instance. I'd like to be able to make some dnsmasq.conf changes so that I can only use specific interfaces and use mac-address - ip address mapping. I can do that if I use the /etc/dnsmasq.conf file and start dnsmasq using the init.d startup scripts... but when kvm / libvirt does dnsmasq... it doesn't use the default config file. ... but I'm not sure there are many people knowledgeable about dnsmasq here. I certainly know nothing about it. You might try on the libvirt lists. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] [2/2] Moving kvm_vcpu_cache to x86.c
Avi Kivity wrote: Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 29 Nov 2007 15:45:57 +0800 Subject: [PATCH] Moving kvm_vcpu_cache to x86.c. Moving kvm_vcpu_cache to x86.c, since only x86 platform will use to align the memory area for fx_save. How about having a KVM_VCPU_ALIGN macro, defined to zero except for x86? Alternatively (possibly better as it saves some memory), move the fpu state out of kvm_vcpu (accessed via a pointer). Both should be OK. But now that other archs have no such issues, maybe we can move them to x86 first:) - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0 of 3] create kvm_x86
Zhang, Xiantao wrote:
The nicer one:
struct kvm {
struct kvm_arch arch;
// common fields
}
I prefer this one, seems it is more direct and readable. Same thinking
about kvm_vcpu structure:)
I agree, kvm_vcpu should use the same method.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Eliminate the difference of ioapic andiosapic
Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 29 Nov 2007 18:17:13 +0800 Subject: [PATCH] Clearing up the difference of ioapic and iosapic Since IA64 uses iosapic, we want to merget it with current ioapic code. This patch should make x86 and IA64 happy. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] --- drivers/kvm/ioapic.c | 26 +- drivers/kvm/irq.h|5 +++-- drivers/kvm/lapic.c | 23 ++- 3 files changed, 34 insertions(+), 20 deletions(-) diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c index cf1d50b..79c48ec 100644 --- a/drivers/kvm/ioapic.c +++ b/drivers/kvm/ioapic.c @@ -36,11 +36,8 @@ #include asm/page.h #include asm/current.h -#include asm/apicdef.h -#include asm/io_apic.h This will break compilation under certain .configs. Other than that, the patch is good. Can we use the compile option CONFIG_X86 to handle it ? Xiantao Sure. But where does ia64 get its ioapic defines then? Things like dest_Fixed, I grepped for them in include/asm-ia64 but didn't find them. Maybe an include/asm-ia64/io_apic.h can provide them? In IA64, it uses macros to define them for iosapic side. Seems only io_apic.h should be included for dest_Fixed reference, and apicdef is not necessary here. Now, I defined it in IA64-specific head file, (e.g.) ia64.h. Here, I don't think we can define io_apic.h under asm-ia64, since the similar definition exists in iosapic.h. Maybe we can removed the include here, and just define an common macro such kvm_dest_Fixed and kvm_dest_Low_Prio in irq.h to solve it, and make kvm not dependent of kernel's head files here. What's your opinion? Hm... I guess we can have a drivers/kvm/ioapic.h which will contain the definitions for io[s]apic, and drop the dependency on asm-x86/io_apic.h. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/2 Patches to furthure split kvm_init
Hollis Blanchard wrote: On Fri, 2007-11-30 at 16:50 +0200, Avi Kivity wrote: Carsten Otte wrote: Avi Kivity wrote: But you do need the vcpu cache, right? I think about organizing our SIE control blocks in it, just like vmx and svm do with their hardware structures backing a vcpu state. They're 512 bytes in size, and need to start on a 512-byte boundary. Sorry about my previous answer, I was confused by vcpu_cache / vcpu_decache for x86. It's friday... Ah, so you even need the alignment (which happen to be exactly the x86 fpu alignment). So we have two archs needing special allocation, and two archs using a common allocator. I think it's clear that this is an area that is likely to be very architecture-specific, and I don't think that duplicating kmem_cache_create() for each architecture is a big deal at all. No, it isn't, but having a KVM_ARCH_HAS_VCPU_ALLOC isn't either. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
