>From: Tian, Kevin
>Sent: 2006年3月28日 15:24
>
>If possible, I suggest you to use terms defined in include/public/xen.h from
>now on:
>Gpfn/gmfn/mfn/pfn,
>with clear explanation in head of that file. :-)
>
My fault. It's include/xen/mm.h.
Thanks,
Kevin
>From: Isaku Yamahata
>Sent: 2006年3月24日 17:46
>
>* grant table API proposal
>The current grant table API depends on xen/x86 deeply.
>There are four kind of addresses related to grant table.
>user virtual address, kernel virtual address, pseudo physical address and
>machine address.
>xen/x86 grant t
Sorry for ugly alignment.
Maybe this one will be better:)
This patch intends to fix domainU boot after VTi domain booted up.
Currently domainU can't boot after domain VTi booted up. The root cause
is when VTi domain exists, after DomU createing and being scheduled for
first time, context_switch wo
This patch intends to fix domainU boot after VTi domain booted
up.
Currently domainU can't boot after domain VTi booted up. The root cause
is
when VTi domain exists, after DomU createing and being scheduled for
first time,
context_switch won't be executed completely but through another
exe
Hi Tristan.
+ /* Purge tc entry.
+ Can we do this directly ? Well, this is just a
+ single atomic write. */
+ vcpu_purge_tr_entry(&PSCBX(v,dtlb));
+ vcpu_purge_tr_entry(&PSCBX(v,
>From: Magenheimer, Dan (HP Labs Fort Collins)
>[mailto:[EMAIL PROTECTED]
>
>Hmmm... Kevin, you may be right. My memory is dim on this
>(as it was >15 months ago), but at some point an fc instruction
>in linux did cause an unexpected trap. This was back when
>I was still working with a privified
On Mon, 2006-03-27 at 14:15 +0100, Tristan Gingold wrote:
> Le Lundi 27 Mars 2006 15:07, Alex Williamson a écrit :
> > On Mon, 2006-03-27 at 13:53 +0100, Tristan Gingold wrote:
> > > Hi,
> > >
> > > this is a very simple extension of vcpu_ptc_ga to support SMP-g.
> > > The implementation could be o
On Mon, 2006-03-27 at 20:20 +0800, Tian, Kevin wrote:
> Move SHAREDINFO_ADDR and SHARED_ARCHINFO_ADDR to be
> adjacent, which makes easier to access two areas by offset upon same
> base.
>
> Also remove duplicated XSI_ definitions in asm-offsets.c.
Applied.
--
Alex Williamson
On Mon, 2006-03-27 at 13:38 +0800, Tian, Kevin wrote:
> Same as last patch for asm-offsets.h, asm-xsi-offsets.h also needs to be
>
> re-compiled when header files change, or else there'll still be window
> for
> xenlinux to see mismatched offsets definition.
>
> Also remove unused definitions in
On Mon, 2006-03-27 at 11:26 +0800, Tian, Kevin wrote:
> Clean up to xen time handler. Tristan #if 0 some code because it seems
> redundant, which however is actually problematic logic as a reason for
> an intermittent timer oops issue of dom0. So delete it now.
>
> Also remove vcpu_wake, since wak
Add -xen buildconfig for ia64 and tweak CONFIG_VT setup to avoid
initializing on domUs. Remove CONFIG_IDE_GENERIC as this is unnecessary
on ia64 systems (no ISA IDE controllers) and causes long timeouts
booting domU. Please apply. Thanks,
Alex
--
Alex Williamson
On Mon, 2006-03-27 at 18:24 +0100, Ian Pratt wrote:
> >I'll work on it and either submit a Makefile hack or a
> > suitable -xen config. I think xencons vs serial console is
> > the main thing preventing a combined config file. Thanks,
>
> Could you elaborate a bit? How is it different from
People are asking how to boot DomainU, so here is --
1. Follow
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-03/msg00362
.html to build the Xen and Domain0/U binary
2. Follow DomainU image creation steps described bellow
3. Create boot config file for DomainU
4. Follow DomainU b
>I'll work on it and either submit a Makefile hack or a
> suitable -xen config. I think xencons vs serial console is
> the main thing preventing a combined config file. Thanks,
Could you elaborate a bit? How is it different from x86?
Thanks,
Ian
_
Hmmm... Kevin, you may be right. My memory is dim on this
(as it was >15 months ago), but at some point an fc instruction
in linux did cause an unexpected trap. This was back when
I was still working with a privified kernel, probably older
than 2.6.9. IIRC, the problem occurred during one of the
On Mon, 2006-03-27 at 18:05 +0100, Ian Pratt wrote:
> >FYI, cset 9434 (Switch the default build to make the -xen
> > kernel, not the -xen0 and -xenU) breaks xen/ia64 as we do not
> > currently have a linux-defconfig-xen_ia64. I don't
> > understand why such a change is being made so close t
>FYI, cset 9434 (Switch the default build to make the -xen
> kernel, not the -xen0 and -xenU) breaks xen/ia64 as we do not
> currently have a linux-defconfig-xen_ia64. I don't
> understand why such a change is being made so close to Xen
> 3.0.2. Can we make this architecture dependent?
C
On 27 Mar 2006, at 17:49, Alex Williamson wrote:
FYI, cset 9434 (Switch the default build to make the -xen kernel,
not
the -xen0 and -xenU) breaks xen/ia64 as we do not currently have a
linux-defconfig-xen_ia64. I don't understand why such a change is
being
made so close to Xen 3.0.2. C
FYI, cset 9434 (Switch the default build to make the -xen kernel, not
the -xen0 and -xenU) breaks xen/ia64 as we do not currently have a
linux-defconfig-xen_ia64. I don't understand why such a change is being
made so close to Xen 3.0.2. Can we make this architecture dependent?
Thanks,
Al
> From: Tristan Gingold [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 27, 2006 8:52 AM
> To: Magenheimer, Dan (HP Labs Fort Collins); Tian, Kevin;
> xen-ia64-devel@lists.xensource.com
> Subject: Re: [Xen-ia64-devel] flush.S not para-virtualized
>
> Le Lundi 27 Mars 2006 17:24, Magenheimer, Dan
>From: Tristan Gingold [mailto:[EMAIL PROTECTED]
>Sent: 2006年3月27日 23:52
>
>Le Lundi 27 Mars 2006 17:24, Magenheimer, Dan (HP Labs Fort Collins)
>a écrit :
>> Agreed, this needs to be paravirtualized.
>So, everybody agree.
>I will add a fc.i hyperprivop.
>
>However, I fear the hyperprivop-ized vers
Le Lundi 27 Mars 2006 17:24, Magenheimer, Dan (HP Labs Fort Collins) a écrit :
> Agreed, this needs to be paravirtualized.
So, everybody agree.
I will add a fc.i hyperprivop.
However, I fear the hyperprivop-ized version of flush.S would be very slow.
Should we also create an hyperprivop for some
Agreed, this needs to be paravirtualized.
Dan
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Tian, Kevin
> Sent: Monday, March 27, 2006 5:33 AM
> To: Tristan Gingold; xen-ia64-devel@lists.xensource.com
> Subject: RE: [Xen-ia64-devel] flush.S no
Le Lundi 27 Mars 2006 15:07, Alex Williamson a écrit :
> On Mon, 2006-03-27 at 13:53 +0100, Tristan Gingold wrote:
> > Hi,
> >
> > this is a very simple extension of vcpu_ptc_ga to support SMP-g.
> > The implementation could be optimized.
>
> Hi Tristan,
>
>There's no patch attached, please res
On Mon, 2006-03-27 at 13:53 +0100, Tristan Gingold wrote:
> Hi,
>
> this is a very simple extension of vcpu_ptc_ga to support SMP-g.
> The implementation could be optimized.
Hi Tristan,
There's no patch attached, please resend. Thanks,
Alex
--
Alex Williamson
Hi,
this is a very simple extension of vcpu_ptc_ga to support SMP-g.
The implementation could be optimized.
Tested by boot+halt of dom0+domU.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-i
>From: Tristan Gingold [mailto:[EMAIL PROTECTED]
>Sent: 2006年3月27日 20:32
>
>Le Lundi 27 Mars 2006 14:22, Tian, Kevin a écrit :
>> From: Tristan Gingold
>>
>> >Sent: 2006年3月27日 20:22
>> >
>> >Hi,
>> >
>> >unless I am wrong, arch/ia64/lib/flush.S is not para-virtualized.
>> >However, it
>> >has an 'f
Le Lundi 27 Mars 2006 14:22, Tian, Kevin a écrit :
> From: Tristan Gingold
>
> >Sent: 2006年3月27日 20:22
> >
> >Hi,
> >
> >unless I am wrong, arch/ia64/lib/flush.S is not para-virtualized.
> >However, it
> >has an 'fc' instruction. Is it expected ?
> >
> >Tristan.
>
> If based on previous discussion
>From: Tristan Gingold
>Sent: 2006年3月27日 20:22
>
>Hi,
>
>unless I am wrong, arch/ia64/lib/flush.S is not para-virtualized.
>However, it
>has an 'fc' instruction. Is it expected ?
>
>Tristan.
>
>
If based on previous discussion, seems same case to be fixed...
Thanks,
Kevin
___
Move SHAREDINFO_ADDR and SHARED_ARCHINFO_ADDR to be
adjacent, which makes easier to access two areas by offset upon same
base.
Also remove duplicated XSI_ definitions in asm-offsets.c.
Signed-off-by Kevin Tian <[EMAIL PROTECTED]>
(Please apply attached patch against below thread, due to some d
Hi,
unless I am wrong, arch/ia64/lib/flush.S is not para-virtualized. However, it
has an 'fc' instruction. Is it expected ?
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Hi.
On Fri, Mar 24, 2006 at 11:11:38PM +0800, Tian, Kevin wrote:
> A quality writing and good work by far. Due to memory model as the
> most critical/basic component, your work is actually extended to cover
> many areas as the issues posted below. :-) Maybe you have to make a
> priority
32 matches
Mail list logo
