Re: [Qemu-devel] [PATCH 3/6] Enable KVM for ppcemb.

2008-12-13 Thread Anthony Liguori

Hollis Blanchard wrote:

On Thu, 2008-12-11 at 16:54 -0600, Hollis Blanchard wrote:
  

I don't know that kvm_ppc.c is a very information name for this sort
  
of 


stuff.  Since this is really host specific, not target specific, why
  
not 


move it out of target-ppc.
  

I could combine kvm_ppc.c into target-ppc/kvm.c. However, they're
really
two different things, and I thought it would cause the least confusion
if they were logically separate. Most of it is hooks required by
common
code, and then some of it isn't. (I'm thinking about e.g. IA64 doing a
copy/paste, and then wondering which functions they actually need to
implement.) Regardless, I will still need a kvm_ppc.h, so kvm_ppc.c
seemed like a good place to match.



Any further thoughts on this issue? It's the only issue I still have
unresolved from the initial reviews.
  


No, we can fix it later when someone comes up with a better idea.

Regards,

Anthony Liguori


--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH 3/6] Enable KVM for ppcemb.

2008-12-13 Thread Hollis Blanchard
On Thu, 2008-12-11 at 16:54 -0600, Hollis Blanchard wrote:
> 
> > I don't know that kvm_ppc.c is a very information name for this sort
> of 
> > stuff.  Since this is really host specific, not target specific, why
> not 
> > move it out of target-ppc.
> 
> I could combine kvm_ppc.c into target-ppc/kvm.c. However, they're
> really
> two different things, and I thought it would cause the least confusion
> if they were logically separate. Most of it is hooks required by
> common
> code, and then some of it isn't. (I'm thinking about e.g. IA64 doing a
> copy/paste, and then wondering which functions they actually need to
> implement.) Regardless, I will still need a kvm_ppc.h, so kvm_ppc.c
> seemed like a good place to match.

Any further thoughts on this issue? It's the only issue I still have
unresolved from the initial reviews.

-- 
Hollis Blanchard
IBM Linux Technology Center

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH 2/6] kvm: sync vcpu state during initialization

2008-12-13 Thread Anthony Liguori

Hollis Blanchard wrote:

On Fri, 2008-12-12 at 18:23 -0600, Hollis Blanchard wrote:
  

When I use "-cpu coreduo" (for some strange reason "core2duo" is not
recognized), I don't segfault.



I didn't have TARGET_X86_64, so that explains the missing core2duo...
  


I'm a bit confused.  You were running -enable-kvm with qemu (as opposed 
to qemu-system-x86_64)?


Regards,

Anthony Liguori


--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub

2008-12-13 Thread Jan Kiszka
Christian Ehrhardt wrote:
> Hollis Blanchard wrote:
>> On Thu, 2008-12-11 at 17:05 +0100, Jan Kiszka wrote:
>>  
>>> Hollis Blanchard wrote:
>>>
 On Thu, 2008-12-11 at 13:53 +0100, Christian Ehrhardt wrote:
  
> This is v2 as version one had a type in it occured when splitting
> patches.
> Mercurial somehow lost my changes to the patch description
> explaining that, but the patch is right this way.
>
> Christian Ehrhardt wrote:
>
>> # HG changeset patch
>> # User Christian Ehrhardt
>> 
>> # Date 1228999833 -3600
>> # Node ID dc1466c9077ab162f4637fffee1869f26be02299
>> # Parent  4c07fe2a56c7653a9113e05bb08c2de9aec210ce
>> [PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu
>> gdbstub
>>
>> From: Hollis Blanchard
>> 
>>
>> Add basic KVM PowerPC support to qemu's gdbstub introducing a kvm
>> ppc style
>> mmu implementation that uses the kvm_translate ioctl.
>> This also requires to save the kvm registers prior to the 'm' gdb
>> operations.
>>
>> Signed-off-by: Hollis Blanchard
>> 
>> Signed-off-by: Christian Ehrhardt
>> 
>>   
 Let's *not* apply this to kvm-userspace. We will submit this to qemu,
 and once we work out the right solution there it will be merged
 naturally.

   
>>> I don't oversee yet what you want to push upstream, but in case it's the
>>> gdbstub support for kvm (including ppc bits): please note that I plan to
>>> push the new interface once it is merged into kvm-userspace, avoiding to
>>> spread the current, limited one as far as possible.
>>>
>>> BTW, would be great if you could have a look / provide patches for ppc
>>> to support the new interface already. I am open for feedback,
>>> specifically regarding its suitability beyond x86.
>>> 
>>
>> I've been meaning to do this for a while, sorry. We'll take a look soon.
>>
>>   
> Hi Jan,
> I saw that you already had that env->s->g_cpu fix, so if you change all
> that
> anyway it might really be better to test/extend your patches for powerpc
> now.
> 
> If it is ok for you I would submit my patches that apply on top of yours to
> you and cc the kvm list. But as Hollis mentioned I would prefer go for qemu
> upstream first and then assist Avi in merging it into kvm-userspace because
> this is the natural direction patches flow atm (and if you need to
> change it
> multiple times until you get qemu acceptance you would have to extensivly
> patch both projects to match again).

My current roadmap is first merging kernel bits and corresponding
kvm-userspace changes so that we can test both extensively in the
context of full-blown kvm, and then push an adopted userspace interface
into qemu. The other way around would create the risk of missing
problems that only pop up under full-featured kvm (upstream is still
fairly limited, specifically as there is no threaded smp support).

That said, if you have (ppc-)changes that can be pushed immediately and
independently, there is surely no need to wait for the kvm-gdb series.

> 
> As my code in that case depend on your patches it would be nice if you
> could
> put them into your series once you are happy with it.
> 

I will happily carry them, no problem.

Jan



signature.asc
Description: OpenPGP digital signature


Re: [PATCH] [PATCH] kvm-userspace: gdb: fix new gdb function types

2008-12-13 Thread Jan Kiszka
Christian Ehrhardt wrote:
> # HG changeset patch
> # User Christian Ehrhardt 
> # Date 1229085659 -3600
> # Node ID 37967a80a2757505488685aac135681945e6da91
> # Parent  f0ed33f14658fe91a14ec02501cb42d26e32f01f
> [PATCH] kvm-userspace: gdb: fix new gdb function types
> 
> From: Christian Ehrhardt 
> 
> The types changed in the header but not in the powerpc and ia64 
> implementation.
> This patch fix that build error by changing the stubs to the right prototype.

Thanks for the fix! Will merge it into the master patch, adding your
signed-off - if that's fine for you.

Jan



signature.asc
Description: OpenPGP digital signature