kvm-ia64-devel — kvm ia64 port development

[kvm-ia64-devel] booting recent kernels

[Jes S. <je...@sg...>]

Hi,

I am still having the problems booting recent ia64 kernels that I build
here.

Anyone who is having luck with a recent kernel? Which compiler did you
use to build it? Any chance you could share your .config?

Thanks,
Jes

[kvm-ia64-devel] Wanted Urgently

[Dr R. Hansmond. <han...@ya...>]

新しいメールアドレスをお知らせします新しいメールアドレス： han...@ya...

I am seeking your cooperation in building a Tourist Hotel or Real Estate in your country.I need an experienced person like you to assist me to set up, develop the project.


Alternative Email:- han...@ya...


Thanks and God bless.

Dr Raymond Hansmond.

- Dr Raymond Hansmond.

[kvm-ia64-devel] [ANNOUNCE] kvm mailing lists moving

[Avi K. <av...@qu...>]

In about a week, the various kvm lists will move to vger.kenel.org.  
This will improve responsiveness, and reduce spam and advertising.

Please subscribe to the lists you are interested in as soon as 
possible.  You can subscribe by sending an email to 
maj...@vg..., with the following lines in the body:

subscribe kvm
subscribe kvm-commits
subscribe kvm-ia64
subscribe kvm-ppc

Of course, omit lines for the lists you are not interested in.  
Majordomo will then send further instructions.

Thanks to the vger admins for hosting the kvm lists.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [kvm-ia64-devel] [kvm-devel] Moving kvm lists to kernel.org?

[Avi K. <av...@qu...>]

David Miller wrote:
> I've created (and tested) all of these lists.
>
>   

Thanks. I about a week I'll make the sourceforge lists read-only.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [kvm-ia64-devel] Moving kvm lists to kernel.org?

[David M. <da...@da...>]

From: Avi Kivity <av...@qu...>
Date: Wed, 30 Apr 2008 00:46:13 +0300

> I sent an email a couple of days ago to pos...@vg...:
> 
> > Hi, please create the following lists for kvm:
> >
> >  kvm (x86 and general discussion)
> >  kvm-ppc (powerpc, managed by Hollis Blanchard)
> >  kvm-ia64 (ia64)
> >  kvm-commits (read-only, tracks commits to kvm git HEAD)
> >
> > Thanks. 

I've created (and tested) all of these lists.

Re: [kvm-ia64-devel] Moving kvm lists to kernel.org?

[Avi K. <av...@qu...>]

David Miller wrote:
> Should I create the list(s) now?  If so, please let me know the
> names they should have.
>   

I sent an email a couple of days ago to pos...@vg...:

> Hi, please create the following lists for kvm:
>
>  kvm (x86 and general discussion)
>  kvm-ppc (powerpc, managed by Hollis Blanchard)
>  kvm-ia64 (ia64)
>  kvm-commits (read-only, tracks commits to kvm git HEAD)
>
> Thanks. 

Thanks.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [kvm-ia64-devel] Moving kvm lists to kernel.org?

[David M. <da...@da...>]

From: Avi Kivity <av...@qu...>
Date: Sun, 27 Apr 2008 12:40:29 +0300

> Avi Kivity wrote:
> > I propose moving the kvm lists to vger.kernel.org, for the following 
> > benefits:
> >
> > - better spam control
> > - faster service (I see significant lag with the sourceforge lists)
> > - no ads appended to the end of each email
> >
> > If no objections are raised, and if the vger postmasters agree, I will 
> > mass subscribe the current subscribers so that there will be no 
> > service interruption.
> >
> 
> Since no objections were raised, we'll start to get this rolling.

Should I create the list(s) now?  If so, please let me know the
names they should have.

Thanks.

Re: [kvm-ia64-devel] [PATCH] ia64 kvm fixes for O=... builds

[Al V. <vi...@Ze...>]

On Mon, Apr 28, 2008 at 03:14:02PM +0100, Al Viro wrote:
> On Mon, Apr 28, 2008 at 09:46:44PM +0800, Zhang, Xiantao wrote:
> > >  kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o
> > >  	mmio.o \ vtlb.o process.o
> > >  #Add link memcpy and memset to avoid possible structure assignment
> > > error -kvm-intel-objs += memset.o memcpy.o
> > > +kvm-intel-objs += ../lib/memset.o ../lib/memcpy.o
> > >  obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
> > 
> > I don't think it is workable for kvm-ia64.  Currently,  kvm-intel module
> > needs to be relocated at insertion time, so the code is
> > position-indenpent. Howerver, lib/*.memset.o(memcoy.o) are not compiled
> > as position independent code, they can't be linked into the module
> > correctly in your way. That is why we use symbol link instead of linking
> > the objects under /lib. 
> 
> symlinks won't work as you use them.  If you really need separately
> compiled, use file with a couple of #include "../lib/......S" and
> be done with that.

... like this, perhaps?  I still wonder what will happen with either this
or the original tree if you make CONFIG_KVM_INTEL=y, though - won't either
variant give you duplicate symbols?

diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
index 5235339..e7b9432 100644
--- a/arch/ia64/kvm/Makefile
+++ b/arch/ia64/kvm/Makefile
@@ -54,5 +54,5 @@ EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
 kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o mmio.o \
 	vtlb.o process.o
 #Add link memcpy and memset to avoid possible structure assignment error
-kvm-intel-objs += ../lib/memset.o ../lib/memcpy.o
+kvm-intel-objs += memset.o memcpy.o
 obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
diff --git a/arch/ia64/kvm/memcpy.S b/arch/ia64/kvm/memcpy.S
new file mode 100644
index 0000000..c04cdbe
--- /dev/null
+++ b/arch/ia64/kvm/memcpy.S
@@ -0,0 +1 @@
+#include "../lib/memcpy.S"
diff --git a/arch/ia64/kvm/memset.S b/arch/ia64/kvm/memset.S
new file mode 100644
index 0000000..83c3066
--- /dev/null
+++ b/arch/ia64/kvm/memset.S
@@ -0,0 +1 @@
+#include "../lib/memset.S"

Re: [kvm-ia64-devel] [PATCH] ia64 kvm fixes for O=... builds

[Al V. <vi...@Ze...>]

On Mon, Apr 28, 2008 at 09:46:44PM +0800, Zhang, Xiantao wrote:
> >  kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o
> >  	mmio.o \ vtlb.o process.o
> >  #Add link memcpy and memset to avoid possible structure assignment
> > error -kvm-intel-objs += memset.o memcpy.o
> > +kvm-intel-objs += ../lib/memset.o ../lib/memcpy.o
> >  obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
> 
> I don't think it is workable for kvm-ia64.  Currently,  kvm-intel module
> needs to be relocated at insertion time, so the code is
> position-indenpent. Howerver, lib/*.memset.o(memcoy.o) are not compiled
> as position independent code, they can't be linked into the module
> correctly in your way. That is why we use symbol link instead of linking
> the objects under /lib. 

symlinks won't work as you use them.  If you really need separately
compiled, use file with a couple of #include "../lib/......S" and
be done with that.

Re: [kvm-ia64-devel] [PATCH] ia64 kvm fixes for O=... builds

[Zhang, X. <xia...@in...>]

Al Viro wrote:
> * EXTRA_CFLAGS do not apply for *.S
> * don't bother with symlinks to ../lib/mem*.S, just add ../lib/mem*.o
>   to object list
> 
> Signed-off-by: Al Viro <vi...@ze...>
> ---
>  arch/ia64/kvm/Makefile |    7 ++-----
>  1 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
> index 41b034f..5235339 100644
> --- a/arch/ia64/kvm/Makefile
> +++ b/arch/ia64/kvm/Makefile
> @@ -42,10 +42,7 @@ $(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s
>  #
> 
>  EXTRA_CFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/
> -
> -$(addprefix $(objtree)/,$(obj)/memcpy.S $(obj)/memset.S):
> -	$(shell ln -snf ../lib/memcpy.S $(src)/memcpy.S)
> -	$(shell ln -snf ../lib/memset.S $(src)/memset.S)
> +EXTRA_AFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/
> 
>  common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o)
> 
> @@ -57,5 +54,5 @@ EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
>  kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o
>  	mmio.o \ vtlb.o process.o
>  #Add link memcpy and memset to avoid possible structure assignment
> error -kvm-intel-objs += memset.o memcpy.o
> +kvm-intel-objs += ../lib/memset.o ../lib/memcpy.o
>  obj-$(CONFIG_KVM_INTEL) += kvm-intel.o

I don't think it is workable for kvm-ia64.  Currently,  kvm-intel module
needs to be relocated at insertion time, so the code is
position-indenpent. Howerver, lib/*.memset.o(memcoy.o) are not compiled
as position independent code, they can't be linked into the module
correctly in your way. That is why we use symbol link instead of linking
the objects under /lib. 

Xiantao

[kvm-ia64-devel] [PATCH] ia64 kvm fixes for O=... builds

[Al V. <vi...@ft...>]

* EXTRA_CFLAGS do not apply for *.S
* don't bother with symlinks to ../lib/mem*.S, just add ../lib/mem*.o
  to object list

Signed-off-by: Al Viro <vi...@ze...>
---
 arch/ia64/kvm/Makefile |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
index 41b034f..5235339 100644
--- a/arch/ia64/kvm/Makefile
+++ b/arch/ia64/kvm/Makefile
@@ -42,10 +42,7 @@ $(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s
 #
 
 EXTRA_CFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/
-
-$(addprefix $(objtree)/,$(obj)/memcpy.S $(obj)/memset.S):
-	$(shell ln -snf ../lib/memcpy.S $(src)/memcpy.S)
-	$(shell ln -snf ../lib/memset.S $(src)/memset.S)
+EXTRA_AFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/
 
 common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o)
 
@@ -57,5 +54,5 @@ EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
 kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o mmio.o \
 	vtlb.o process.o
 #Add link memcpy and memset to avoid possible structure assignment error
-kvm-intel-objs += memset.o memcpy.o
+kvm-intel-objs += ../lib/memset.o ../lib/memcpy.o
 obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
-- 
1.5.3.GIT

[kvm-ia64-devel] [UPDATED][ANNOUNCE] Preliminary KVM Forum 2008 Agenda

[Avi K. <av...@qu...>]

The preliminary KVM Forum 2008 agenda at

   http://kforum.qumranet.com/KVMForum/agenda.php

has been updated, with a few more new presentations added.  Be sure to 
check them out.  Note we still have a couple more in the pipeline.

If you haven't done so already, please register!  There is a big
"Register Now" button on the page.  Early bird registration ends May 1.

Note we have a few more sessions in the pipeline; the page will be
updated in a few days.

[Speakers: if we've misspelled your name or if you'd like to change your
slot, let us know]

-- 
Do not meddle in the internals of kernels, for they are subtle and quick 
to panic.

Re: [kvm-ia64-devel] Moving kvm lists to kernel.org?

[Avi K. <av...@qu...>]

Avi Kivity wrote:
> I propose moving the kvm lists to vger.kernel.org, for the following 
> benefits:
>
> - better spam control
> - faster service (I see significant lag with the sourceforge lists)
> - no ads appended to the end of each email
>
> If no objections are raised, and if the vger postmasters agree, I will 
> mass subscribe the current subscribers so that there will be no 
> service interruption.
>

Since no objections were raised, we'll start to get this rolling.


-- 
error compiling committee.c: too many arguments to function

Re: [kvm-ia64-devel] EFI image / SCSI support

[<tgi...@fr...>]

Quoting Jes Sorensen <je...@sg...>:

> Tristan Gingold wrote:
> > I see.  Note that tianocore contains all the code for USB mass storage.
> Might
> > this help ?
>
> Hmmm, I would have to look into this. I don't know if qemu can present
> a USB storage device, but it might be an option. Will EFI boot off USB
> mass storage?

Not yet, but that's doable.

Tristan.

Re: [kvm-ia64-devel] IRQ assignment

[Jes S. <je...@sg...>]

>>>>> "Jes" == Jes Sorensen <je...@sg...> writes:

Jes> lspci claims the interrupt is 11, but the IDE driver is able to
Jes> probe and run with interrupts. In that case lspci claims irq 6
Jes> for ide, but /proc/interrupts shows ide configured with
Jes> interrupts 33+34.

Ok,

I think we have a general irq assignment problem. I just tried
modprobing the sym53c8xx driver and I get the same issue that it
cannot obtain an interrupt.

Cheers,
Jes

Re: [kvm-ia64-devel] [kvm-devel] [kvm-ppc-devel] Moving kvm lists to kernel.org?

[Jes S. <je...@sg...>]

>>>>> "Avi" == Avi Kivity <av...@qu...> writes:

Avi> kvm-devel doesn't do manual moderation.  If vger has the
Avi> infrastructure, I don't see why you can't continue doing this on
Avi> kvm-ppc-devel.

Please don't do this for the kvm-ia64 list either.

Avi> btw, we can probably shorten the names to kvm@ and kvm-$arch@
Avi> while we're at it.

Either way works IMHO.

Cheers,
Jes

Re: [kvm-ia64-devel] EFI image / SCSI support

[Jes S. <je...@sg...>]

Tristan Gingold wrote:
> On Thu, Apr 24, 2008 at 04:10:11PM +0200, Jes Sorensen wrote: 
>> Do you know if there's any plans to support SCSI devices in the EFI
>> image?
> 
> EFI from Tianocore contains SCSI layer code but no adapter driver.  So we
> currently can't use it.  
> 
> Which adapter do you plan to use ?  53c895a ?

Hi Tristan,

Just checked, yep thats the one.

>> For KVM I am currently booting with an IDE disk, but it would be
>> really useful if I could boot it with an image showing up as SCSI - it
>> would allow me to boot another system's disk unmodified  :-)
> 
> I see.  Note that tianocore contains all the code for USB mass storage.  Might
> this help ?

Hmmm, I would have to look into this. I don't know if qemu can present
a USB storage device, but it might be an option. Will EFI boot off USB
mass storage?

Cheers,
Jes

Re: [kvm-ia64-devel] EFI image / SCSI support

[Tristan G. <tgi...@fr...>]

On Thu, Apr 24, 2008 at 04:10:11PM +0200, Jes Sorensen wrote:
> Hi Tristan,

Hi Jes,

 
> Do you know if there's any plans to support SCSI devices in the EFI
> image?

EFI from Tianocore contains SCSI layer code but no adapter driver.  So we
currently can't use it.  

Which adapter do you plan to use ?  53c895a ?

> For KVM I am currently booting with an IDE disk, but it would be
> really useful if I could boot it with an image showing up as SCSI - it
> would allow me to boot another system's disk unmodified  :-)

I see.  Note that tianocore contains all the code for USB mass storage.  Might
this help ?

Tristan.

Re: [kvm-ia64-devel] Moving kvm lists to kernel.org?

[Andi K. <an...@fi...>]

David Miller <da...@da...> writes:

> I'm fine with adding the list, but we don't do mass subscribes like
> that, and this rule applies to every list which moves to vger from
> somewhere else.
>
> People will need to subscribe themselves to the new list.

Can someone please resubscribe gmane too for us gmane users when
the move occurs?
Thanks,
-Andi

Re: [kvm-ia64-devel] [kvm-ppc-devel] Moving kvm lists to kernel.org?

[Hollis B. <ho...@us...>]

On Thursday 24 April 2008 07:54:10 Avi Kivity wrote:
> I propose moving the kvm lists to vger.kernel.org, for the following 
> benefits:
> 
> - better spam control
> - faster service (I see significant lag with the sourceforge lists)
> - no ads appended to the end of each email
> 
> If no objections are raised, and if the vger postmasters agree, I will 
> mass subscribe the current subscribers so that there will be no service 
> interruption.

Sounds good to me.

Will we continue to have manual moderation for non-subscribers? That seems to 
be a good way to handle the last 1% of spam that sneaks through the automated 
filters.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [kvm-ia64-devel] [kvm-ppc-devel] Moving kvm lists to kernel.org?

[Avi K. <av...@qu...>]

Hollis Blanchard wrote:
> On Thursday 24 April 2008 07:54:10 Avi Kivity wrote:
>   
>> I propose moving the kvm lists to vger.kernel.org, for the following 
>> benefits:
>>
>> - better spam control
>> - faster service (I see significant lag with the sourceforge lists)
>> - no ads appended to the end of each email
>>
>> If no objections are raised, and if the vger postmasters agree, I will 
>> mass subscribe the current subscribers so that there will be no service 
>> interruption.
>>     
>
> Sounds good to me.
>
> Will we continue to have manual moderation for non-subscribers? That seems to 
> be a good way to handle the last 1% of spam that sneaks through the automated 
> filters.
>   

kvm-devel doesn't do manual moderation.  If  vger has the 
infrastructure, I don't see why you can't continue doing this on 
kvm-ppc-devel.

btw, we can probably shorten the names to kvm@ and kvm-$arch@ while 
we're at it.

-- 
error compiling committee.c: too many arguments to function

[kvm-ia64-devel] EFI image / SCSI support

[Jes S. <je...@sg...>]

Hi Tristan,

Do you know if there's any plans to support SCSI devices in the EFI
image?

For KVM I am currently booting with an IDE disk, but it would be
really useful if I could boot it with an image showing up as SCSI - it
would allow me to boot another system's disk unmodified  :-)

Cheers,
Jes

PS: Resending - got the wrong mailing list on CC before.

Re: [kvm-ia64-devel] Moving kvm lists to kernel.org?

[Avi K. <av...@qu...>]

David Miller wrote:
>> If no objections are raised, and if the vger postmasters agree, I will 
>> mass subscribe the current subscribers so that there will be no service 
>> interruption.
>>     
>
> I'm fine with adding the list, but we don't do mass subscribes like
> that, and this rule applies to every list which moves to vger from
> somewhere else.
>
>   

(three lists)

> People will need to subscribe themselves to the new list.
>   

Okay.  Will give people a week's notice to subscribe.

-- 
error compiling committee.c: too many arguments to function

Re: [kvm-ia64-devel] Moving kvm lists to kernel.org?

[David M. <da...@da...>]

From: Avi Kivity <av...@qu...>
Date: Thu, 24 Apr 2008 15:54:10 +0300

> I propose moving the kvm lists to vger.kernel.org, for the following 
> benefits:
> 
> - better spam control
> - faster service (I see significant lag with the sourceforge lists)
> - no ads appended to the end of each email
> 
> If no objections are raised, and if the vger postmasters agree, I will 
> mass subscribe the current subscribers so that there will be no service 
> interruption.

I'm fine with adding the list, but we don't do mass subscribes like
that, and this rule applies to every list which moves to vger from
somewhere else.

People will need to subscribe themselves to the new list.

We enforce this for two reasons:

1) If they don't go through the action of subscribing, they
   won't be able to unsubscribe, so they'll be upset and
   also bug us postmasters for help.

2) People are generally unhappy when they are subscribed to
   mailing lists at a site they didn't ask to be at.

Re: [kvm-ia64-devel] [kvm-devel] Moving kvm lists to kernel.org?

[Jes S. <je...@sg...>]

>>>>> "Avi" == Avi Kivity <av...@qu...> writes:

Avi> I propose moving the kvm lists to vger.kernel.org, for the
Avi> following benefits:

Avi> - better spam control - faster service (I see significant lag
Avi> with the sourceforge lists) - no ads appended to the end of each
Avi> email

Avi> If no objections are raised, and if the vger postmasters agree, I
Avi> will mass subscribe the current subscribers so that there will be
Avi> no service interruption.

Avi> Opinions?

Pretty please! The sooner, the better!

Cheers,
Jes