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 >> #include >> -#include >> -#include >> > > 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=detail&atid=893831&aid=1840186&group_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 2>&1 || 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=detail&atid=893831&aid=1842160&group_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=detail&atid=893831&aid=1842160&group_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/2 Patches to furthure split kvm_init
Hollis Blanchard wrote: > 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... > > A kmem_cache is useful for specifying alignment, and as a general bookkeeping system. It's nice to see how many objects you have allocated in /proc/slabinfo, and it will automatically inform you if you have a leak when you unload the module. -- 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 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=detail&atid=893831&aid=1840711&group_id=180599 > > Old issues: > 2. Timer of guest is inaccurate > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1826080&group_id=180599 > 3. Cannot install 64bit vista guests. > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1836905&group_id=180599 > 4. Fails to save/restore guests > https://sourceforge.net/tracker/index.php?func=detail&aid=1824525&group_id=180599&atid=893831 > 5. xp and win2k3 guest crashes > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1819768&group_id=180599 > 6. xpsp2 with 2vpus may fail to boot > https://sourceforge.net/tracker/index.php?func=detail&aid=1805017&group_id=180599&atid=893831 > 7. Cannot boot 32bit smp RHEL5.1 guest on 64bit host > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&group_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-
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/5] qemu: IDE/ATAPI emulation reliability fixes
On Fri, Nov 30, 2007 at 09:15:55AM +0200, Avi Kivity wrote: > Carlo Marcelo Arenas Belon wrote: > > The following patch series implements fixes to the IDE/ATAPI emulation > > in qemu which are already committed upstream or proposed for inclusion; > > including 2 serious regressions that result in availability and data loss > > problems when using OpenSolaris or FreeBSD guests (at least) by the first 2: > > > > Patch 1/5 : fixes GET_CONFIGURATION to allow OpenSolaris cdrom access > > Patch 2/5 : fixes IDE sector write operations resulting in data lost > > Patch 3/5 : enables ACPI interrupts > > Patch 4/5 : uses DVD-ROM as model name for INQUIRY and IDENTIFY DEVICE > > Patch 5/5 : removes obsolete triton chip support > > > > They had been tested in Gentoo Linux 2007.0 amd64 using an Intel Core 2 > > 6320 host and several different versions of FreeBSD, OpenBSD, NetBSD, Linux, > > OpenSolaris and Windows 2000 guests > > Thanks; the last time I tried to merge qemu I had several regressions. some of the patches I cherry picked from qemu cvs are part of the last import in the qemu-vendor-drops branch but since they had not been yet merged (as you mention) I though it was better to cherry pick them from now to expedite this patch. > I'll try again soon once these are merged (or merge them myself if > qemu-devel takes too long). 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. Carlo - 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] Eliminate the difference of ioapic andiosapic
Avi Kivity wrote: > 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 >> #include >> -#include >> -#include >> >> >> > 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. Fine. OK, I will update the patch :) - 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] Eliminate the difference of ioapic andiosapic
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 #include -#include -#include >>> 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? 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] [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? > > > 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? On one hand we don't have "these" alignment issues, but on the other hand we have some complex offset logic to integrate structures and handler vectors&code (which need special alignment). The major problem is that the our prototype currently only supports one vcpu per guest and therefore we didn't think a lot about e.g. kmem_cache for vcpu structures. >From my current point of view we may be able to use a kmem_cache and be able >to do all sophisticated ppc stuff in an arch function filling the arch part of >vcpu, but that opinion may change when we look further into it while >implementing muli-vcpu support per guest. Because of that I think atm your CONFIG_HAVE_SPECIAL_VCPU_ALLOC suggestion would be nice, with that we could do either way later without restructuring the generic code too much. I added Hollis to the direct CC List, because this ppc code is his creation he might be able to give us a much clearer insight how ppc vcpu allocation in future might look like. > Maybe we should just #ifndef CONFIG_IA64 (or #ifdef > CONFIG_HAVE_SPECIAL_VCPU_ALLOC) this bit instead of duplicating it for > s390 and ppc. > -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization +49 7031/16-3385 [EMAIL PROTECTED] [EMAIL PROTECTED] IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 - 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 >>> #include >>> -#include >>> -#include >>> >>> >> 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=detail&atid=893831&aid=1841658&group_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: 80050033 cr4: 6b8 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=detail&atid=893831&aid=1841658&group_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 > #include > -#include > -#include > > > 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
