On Fri, Apr 25, 2008 at 03:36:53PM +0900, Isaku Yamahata wrote:
> On Fri, Apr 25, 2008 at 11:30:57AM +1000, Simon Horman wrote:
> > Index: xen-unstable.hg/xen/arch/ia64/xen/xenasm.S
> > ===
> > --- xen-unstable.hg.orig/xen/arch/ia64/xe
On Fri, Apr 25, 2008 at 11:30:57AM +1000, Simon Horman wrote:
> Index: xen-unstable.hg/xen/arch/ia64/xen/xenasm.S
> ===
> --- xen-unstable.hg.orig/xen/arch/ia64/xen/xenasm.S 2008-04-25
> 11:17:22.0 +1000
> +++ xen-unstable.h
On Fri, Apr 25, 2008 at 03:35:06PM +1000, Simon Horman wrote:
> On Fri, Apr 25, 2008 at 02:38:15PM +1000, Simon Horman wrote:
> > On Fri, Apr 25, 2008 at 06:30:00AM +0200, Tristan Gingold wrote:
> > > [...]
> > >
> > > On Fri, Apr 25, 2008 at 06:25:37AM +0200, Tristan Gingold wrote:
> > > > On Fri
On Fri, Apr 25, 2008 at 02:38:15PM +1000, Simon Horman wrote:
> On Fri, Apr 25, 2008 at 06:30:00AM +0200, Tristan Gingold wrote:
> > [...]
> >
> > On Fri, Apr 25, 2008 at 06:25:37AM +0200, Tristan Gingold wrote:
> > > On Fri, Apr 25, 2008 at 01:57:04PM +1000, Simon Horman wrote:
> > >
> > > To my
On Fri, Apr 25, 2008 at 06:30:00AM +0200, Tristan Gingold wrote:
> [...]
>
> On Fri, Apr 25, 2008 at 06:25:37AM +0200, Tristan Gingold wrote:
> > On Fri, Apr 25, 2008 at 01:57:04PM +1000, Simon Horman wrote:
> >
> > To my best knowledge, this is linux specific (ie not used by Xen except
> > duri
On Fri, Apr 25, 2008 at 06:25:37AM +0200, Tristan Gingold wrote:
> On Fri, Apr 25, 2008 at 01:57:04PM +1000, Simon Horman wrote:
>
> Hi,
>
> I try to fix the comments according to my knowledge.
>
> [...]
> > +/*
> > + * According to xen/arch/ia64/xen/regionreg.c the RID space is broken
> > + * u
[...]
On Fri, Apr 25, 2008 at 06:25:37AM +0200, Tristan Gingold wrote:
> On Fri, Apr 25, 2008 at 01:57:04PM +1000, Simon Horman wrote:
>
> To my best knowledge, this is linux specific (ie not used by Xen except during
> boot time). So I suppose you are explaining how to use an RID compatible
> w
On Fri, Apr 25, 2008 at 01:57:04PM +1000, Simon Horman wrote:
Hi,
I try to fix the comments according to my knowledge.
[...]
> +/*
> + * According to xen/arch/ia64/xen/regionreg.c the RID space is broken
> + * up into chunks, one per domain, and 0th block is for Xen. The 0th block
> + * is broke
Macros to be called by PAL, SAL and EFI to switch into
and out of EFI RID.
Cc: Tristan Gingold <[EMAIL PROTECTED]>
Cc: Isaku Yamahata <[EMAIL PROTECTED]>
Cc: Alex Williamson <[EMAIL PROTECTED]>
Cc: Aron Griffis <[EMAIL PROTECTED]>
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
---
Thu, 22 Nov
On Fri, Apr 25, 2008 at 12:12:54PM +0900, Isaku Yamahata wrote:
> On Thu, Mar 20, 2008 at 05:52:49PM +1100, Simon Horman wrote:
> > Index: xen-unstable.hg/xen/include/asm-ia64/linux-xen/linux/efi.h
> > ===
> > --- xen-unstable.hg.orig/
On Thu, Mar 20, 2008 at 05:52:49PM +1100, Simon Horman wrote:
> Index: xen-unstable.hg/xen/include/asm-ia64/linux-xen/linux/efi.h
> ===
> --- xen-unstable.hg.orig/xen/include/asm-ia64/linux-xen/linux/efi.h
> 2008-04-21 11:39:09.
On Fri, 2008-04-25 at 10:30 +0900, Akio Takebe wrote:
> The above is different from the following log.
> Is this the right elilo entry?
> >>(XEN) Xen command line: BOOT_IMAGE=scsi0:EFI\redhat\xen-3.3.gz root=/dev/
> >>VolGroup00/LogVol00 com1=38400,8n1,0x2f8,45 dom0_mem=2048M
>
> Your elilo.conf s
Akio, thank you for your replies and help so far. I am most grateful.
In my response, I caused confusion by mixing up two different machines on which
I am having this identical problem.
On one machine, I am using RAID1 (root=/dev/md0) and on the other, I am using
LVM.
Let me try again:
Here i
Hi,
>This is the stanza from elilo.conf:
>
>image=vmlinuz-2.6.18.8-xen
>vmm=xen-3.3.gz
>label=xen33
>initrd=initrd-2.6.18.8-xen.img
>read-only
>append="com1=38400,8n1,0x2f8,45 dom0_mem=2048M -- xencons=uart,io,
>0x2f8,38400n8 console=uart,io,0x2f8,38400n8 ro
A cut down version of set_one_rr (and ia64_new_rr7) for
use when switching to the EFI RID for SAL, PAL and EFI calls.
There seems to be no need to repin: palcode, mapped_regs or vhpt in this
case. If it turns they do need to be repinned then special care needs to
betaken to track the correct value
This is the stanza from elilo.conf:
image=vmlinuz-2.6.18.8-xen
vmm=xen-3.3.gz
label=xen33
initrd=initrd-2.6.18.8-xen.img
read-only
append="com1=38400,8n1,0x2f8,45 dom0_mem=2048M --
xencons=uart,io,0x2f8,38400n8 console=uart,io,0x2f8,38400n8 root=/dev/md0"
On Thu, Apr 24, 2008 at 01:46:48PM -0600, Alex Williamson wrote:
> Hi Simon,
>
>This series seems to work ok for me, at least as far as existing
> functionality, I haven't tested kexec. This patch has some commented
> out code (a couple lines in the asm, then a chunk later). Can this be
> cl
Hi,
>(XEN) Xen command line: BOOT_IMAGE=scsi0:EFI\redhat\xen-3.3.gz root=/dev/
>VolGroup00/LogVol00 com1=38400,8n1,0x2f8,45 dom0_mem=2048M
You should check elilo.conf.
The boot parameter should be in dom0 parameter.
Best Regards,
AKio Takebe
___
Xen-
I have an IA64 systems that I had recently booted with xen-3.3-unstable.
Due to circumstances beyond my control, I had to re-install the OS and start
from scratch.
Now, trying to boot it, I see the following on the serial console (and then the
system hangs).
I think I have all the right SCSI dr
On Wed, 2008-04-23 at 17:19 +0800, Xu, Anthony wrote:
> EFI uses 4k page, while xen uses 16k page.
> For dom0, identity mapping are setup for EFI_ACPI_RECLAIM_MEMORY etc.
> It is possible when seting up dom0 memory range which may include some
> EFI_ACPI_RECLAIM_MEMORY due to 4k/16k alignment diffe
Hi Simon,
This series seems to work ok for me, at least as far as existing
functionality, I haven't tested kexec. This patch has some commented
out code (a couple lines in the asm, then a chunk later). Can this be
cleaned out, or should it at least be better commented about why it
remains? T
Hi,
as requested by Yamahata-san (offline) here are the tests that I
performed on these patches.
Kexec: xen->xen(RHEL dom0 + RHEL HVM domain)
rx2620
Kexec: xen->xen->xen (minimal userspace dom0)
rx2620, tiger2
Kexec: xen->xen(RHEL dom0 only)
rx2600
Kexec: xen->linux->xen (min
On Thu, Apr 24, 2008 at 01:52:20PM +0200, Jes Sorensen wrote:
> >+/*
> >+ * PARAVIRT_NR_IRQS is defined by asm-offsets.c as
> >+ * max(IA64_NATIVE_NR_IRQS, XEN_NR_IRQS, ...) depending on config.
> >+ */
> >+#ifndef ASM_OFFSETS_C
> >+#include
> >+#define NR_IRQS PARAVIRT_NR_IRQS
> > #endif
> >
Isaku Yamahata wrote:
On Wed, Apr 23, 2008 at 04:03:58PM +0200, Jes Sorensen wrote:
Isaku Yamahata wrote:
I'd rather have PARAVIRT_NR_IRQ set from Kconfig if possible given that
all of these are constants anyway. If we cannot do that, then it would
be better to do the #if FOO_NR_IRQ > PARAVIRT_
On Wed, Apr 23, 2008 at 04:03:58PM +0200, Jes Sorensen wrote:
> Isaku Yamahata wrote:
> >>I'd rather have PARAVIRT_NR_IRQ set from Kconfig if possible given that
> >>all of these are constants anyway. If we cannot do that, then it would
> >>be better to do the #if FOO_NR_IRQ > PARAVIRT_NR_IRQ in th
On Thu, Apr 24, 2008 at 03:55:15AM +0200, Tristan Gingold wrote:
> On Thu, Apr 24, 2008 at 09:04:01AM +1000, Simon Horman wrote:
> > A cut down version of set_one_rr (and ia64_new_rr7) for
> > use when switching to the EFI RID for SAL, PAL and EFI calls.
>
> Hi,
>
> is it for efficienty or foncti
Hi Simon-san.
VHPT_ENABLED is directly defined in xen/include/asm-ia64/vhpt.h
as "#define VHPT_ENABLED 1"
Thus your patch causes compilation error like the followings.
I guess you need this options for debugging kexec/kdump and
that this option is efficient for vhpt related debugging.
So it's wor
Hi, Isaku
>
>On Wed, Apr 23, 2008 at 01:54:29PM +0900, Akio Takebe wrote:
>Content-Description: Mail message body
>> Hi,
>
>Hi Akio.
>
>
>> This log show that domain_put_page is called 2 times for the same mfn.
>> But the mfn has different mpaddrs.
>> I guess the follwing case is occured:
>> 1. at
On Tue, Apr 22, 2008 at 03:43:18PM +0900, Masaki Kanno wrote:
> I'm not sure that the check is required, though, I think that the
> message is noisy. So, I make a proposal that replaces the printk()
> by gdprintk(XENLOG_DEBUG, ...). What do you think?
Sounds reasonable.
But looking around faul
29 matches
Mail list logo