Add event callback for xen/ia64. Consequently the long
existing hardcode percpu evtchn_irq (0xe9) is abandoned
now.
Currently only inter-domain event channels are injected
by this new path, like virtual drivers. Soon we'll bind
all physical irq/ipi/virq to this path to match our
agreement at last
Hi all,
I'm sorry. I have transmitted an email by mistake.
Best regards,
Kan
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
菅野です。宿題を忘れていました。
以下が、仮想システム開発統括部のxen系のwiki(hiki)です。
近い将来、2)は1)に統合する予定ですのでご承知置きください。
1) 関東地区
http://nrmgr.organic.flab.fujitsu.co.jp/hiki/
2) 沼津地区
http://iavm.soft.fujitsu.com/iavm_hp/hiki/hiki.cgi
3) 小沢グループ
http://www.ark.flab.fujitsu.co.jp/pukiwiki/index.php
※まだ他にありますか? あれば補足願います。
>From: Isaku Yamahata
>Sent: 2006?4?11? 10:14
>> >inside vmx_ivt.S:
>> >
>> >// 0x5400 Entry 24 (size 16 bundles) General Exception (5,32,34,36,38,39)
>> >ENTRY(vmx_general_exception)
>> >VMX_DBG_FAULT(24)
>> >VMX_FAULT(24)
>> >//VMX_REFLECT(24)
>> >END(vmx_general_exception)
>> >
>> >
On Tue, Apr 11, 2006 at 09:17:40AM +0800, Xu, Anthony wrote:
> >inside vmx_ivt.S:
> >
> >// 0x5400 Entry 24 (size 16 bundles) General Exception (5,32,34,36,38,39)
> >ENTRY(vmx_general_exception)
> >VMX_DBG_FAULT(24)
> >VMX_FAULT(24)
> >//VMX_REFLECT(24)
> >END(vmx_general_exception)
>
>From: Alex Williamson
>Sent: 2006?4?11? 8:29
>To: Magenheimer, Dan (HP Labs Fort Collins)
>Cc: Xu, Anthony; xen-ia64-devel@lists.xensource.com
>Subject: RE: [Xen-ia64-devel] [PATCH] [Resend]Enable hash vtlb
>
>On Mon, 2006-04-10 at 16:20 -0700, Magenheimer, Dan (HP Labs Fort
>Collins) wrote:
>
>>
Thank you for testing.
On Mon, Apr 10, 2006 at 03:52:52PM +0100, Tristan Gingold wrote:
> Le Vendredi 07 Avril 2006 06:16, Isaku Yamahata a écrit :
> > Hello.
> > I attached the P2M/VP model patches take 4 for the change set
> > 9492:2133fb78dba3cf6b6b88d1566fc5cc9de3039f43.
> > Please comments/r
Fixed some compilation warnings
Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
Thanks,
-Anthony
warning_fix.diff
Description: warning_fix.diff
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Fixed some compilation warnings
Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
Thanks,
-Anthony
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Hi Alex,
I'll kill off all daemons on native and Dom0, and I'll try
to enlarge memory on Dom0 and DomU.
I'll send out the data later.
Thanks,
Anthony
>From: Alex Williamson
>Sent: 2006?4?10? 23:14
>To: Xu, Anthony
>Cc: xen-ia64-devel@lists.xensource.com
>Subject: RE: [Xen-ia64-devel] [PATCH] [
>From: Magenheimer, Dan (HP Labs Fort Collins)
>Sent: 2006年4月11日 0:21
>
>Even if "time" checks out OK, I am still astonished if domU
>is faster than native and suspect that there is something
>wrong with either the measurement or the methodology.
>
>Dan
Just noted a previous similar report from xe
>From: Tristan Gingold
>Sent: 2006?4?11? 0:03
>To: xen-ia64-devel@lists.xensource.com
>Subject: [Xen-ia64-devel] VT-i: general exception
>
>Hi,
>
>inside vmx_ivt.S:
>
>// 0x5400 Entry 24 (size 16 bundles) General Exception (5,32,34,36,38,39)
>ENTRY(vmx_general_exception)
>VMX_DBG_FAULT(24)
>
On Mon, 2006-04-10 at 16:20 -0700, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> FYI, I did a preliminary test and found that "time" and
> "date +%s" are yielding essentially the same result for dom0,
> even with dom0 also doing Linux builds. So ignore that
> question.
Good to know, thanks
On Tue, 2006-04-11 at 07:30 +0800, You, Yongkang wrote:
> Hi Alex,
>
> I also try some testing in kernel build. I have a curious question.
> Which Cset did you get the result?
I was based on xen-ia64-unstable.hg cset 9503.
> I found some strange unbelievable results after Cset 9495. There ar
Hi Alex,
I also try some testing in kernel build. I have a curious question. Which Cset
did you get the result? I found some strange unbelievable results after Cset
9495. There are only 1100~1200 seconds for kernel building in Xen0 and XenU.
But in 9492, it is still need 1900~2100 seconds.
I a
> I wonder if the time command is appropriate for measuring
> performance in a domU? Are we sure the "real" component
> is measuring elapsed wall clock time? If not, perhaps
> "time" is not accounting for time spent in the hypervisor
> and time spent in dom0 (e.g. backend drivers).
>
> In all my
On Sat, 2006-04-08 at 02:43 +0800, Xu, Anthony wrote:
> Before injecting fault to guest, VMM need to setup
> guest itir by using guest region register.
> But the lowest two bits of itir are reserved. VMM need
> to reset these two bits.
Applied.
--
Alex Williamson H
On Sat, 2006-04-08 at 02:05 +0800, Xu, Anthony wrote:
> As we know, the mechanism for hypervisor to pass parameter through pointer
> is not complete.
Applied.
--
Alex Williamson HP Linux & Open Source Lab
___
Xen-ia64-
On Fri, 2006-04-07 at 12:37 +0100, Tristan Gingold wrote:
> Hi,
>
> thank you for all the discussion about ptc.ga for SMP-g.
> Here is the last patch.
>
> Tested within SMP-g frame by compiling on domU (4+1+1 cpus)
> Tested by boot+halt of dom0+domU.
Applied.
--
Alex Williamson
On Mon, 2006-04-10 at 10:51 -0600, Alex Williamson wrote:
> On Fri, 2006-04-07 at 13:16 +0900, Isaku Yamahata wrote:
>
> > 9512:f5d0a531cb58_dom0_vp_model_xen_part.patch
>
>
>I'm having trouble with the legacy VGA memory descriptor section of
> this patch.
I managed to get my system boot
On Fri, 2006-04-07 at 13:16 +0900, Isaku Yamahata wrote:
> 9512:f5d0a531cb58_dom0_vp_model_xen_part.patch
I'm having trouble with the legacy VGA memory descriptor section of
this patch. It's a big assumption that the platform has VGA. Shouldn't
we be relying on the EFI MDT passed into Xen t
> >> The attachment is the script which I used to get kernel
> build performance.
> >> Usage Example,
> >> ./make_kernel.sh2/root/linux-2.6.16.tar.bz2
> >> (times of build) (absolute path)
> >
> > The attachment seems to have been lost to a virus
> scanner. My test
Hi,
inside vmx_ivt.S:
// 0x5400 Entry 24 (size 16 bundles) General Exception (5,32,34,36,38,39)
ENTRY(vmx_general_exception)
VMX_DBG_FAULT(24)
VMX_FAULT(24)
//VMX_REFLECT(24)
END(vmx_general_exception)
IIRC, VMX_FAULT is an infinite loop. Therefore, in case of general exception
rai
On Mon, 2006-04-10 at 13:55 +0900, Isaku Yamahata wrote:
> I have the following ideas. I think B. or C. might be good.
> What do you think of them?
>
> A. record a huge region to somewhere (maybe struct arch_domain) and
>add region check code to lookup_domian_mpa() (and its families)
>for
On Mon, 2006-04-10 at 23:01 +0800, Xu, Anthony wrote:
> If we configure domU with memory 256MB, domU will complain "at least 256M
> is needed."
> Yes there should a best ratio of memory size of domU and size of VHPT.
My tests are:
dom0: boot w/ dom0_mem=768M, kill off all daemons, build
domU:
>From: Alex Williamson
>Sent: 2006?4?10? 22:33
>On Mon, 2006-04-10 at 22:07 +0800, Xu, Anthony wrote:
>> Hi Alex,
>>
>> Below data is got based on changeset 8489.
>>
>> System:
>> Tiger 4
>> 4G RAM (2GB available to xen)
>> Montecito 1.4GHz dual core dual thread.
>> DomU 512M R
Le Vendredi 07 Avril 2006 06:16, Isaku Yamahata a écrit :
> Hello.
> I attached the P2M/VP model patches take 4 for the change set
> 9492:2133fb78dba3cf6b6b88d1566fc5cc9de3039f43.
> Please comments/request/review.
I am testing this on my FAME-C.
Currently it doesn't work: this is an infinite loop i
On Mon, 2006-04-10 at 22:07 +0800, Xu, Anthony wrote:
> Hi Alex,
>
> Below data is got based on changeset 8489.
>
> System:
> Tiger 4
> 4G RAM (2GB available to xen)
> Montecito 1.4GHz dual core dual thread.
> DomU 512M RAM
Adding memory might be interesting. Perhaps
Hi Alex,
Below data is got based on changeset 8489.
System:
Tiger 4
4G RAM (2GB available to xen)
Montecito 1.4GHz dual core dual thread.
DomU 512M RAM
bare metal (UP):
Total TimeBuild Time 2 Build Time 1
==
>From: Tristan Gingold
>Sent: 2006年4月10日 21:05
>Le Lundi 10 Avril 2006 14:24, Xu, Anthony a écrit :
>> Hi Tristan
>[...]
>> Because it is per VP VHPT, seems it is easier to support SMP-g.
>>
>> In my mind, it's more natural to use IPI to emulate ptc.g.
>In my experience, this is very slow. I will
Le Lundi 10 Avril 2006 14:24, Xu, Anthony a écrit :
> Hi Tristan
[...]
> Because it is per VP VHPT, seems it is easier to support SMP-g.
>
> In my mind, it's more natural to use IPI to emulate ptc.g.
In my experience, this is very slow. I will publish figures later.
> I know your method of emulat
On 10 Apr 2006, at 13:37, Isaku Yamahata wrote:
I'd rather define a function to fill in the entire structure in
gnttab.h.
I hope that the attached patch is much more preferable
than the previous one.
I tested compilation and dom0 boot.
Is the 'phys' parameter to the new functions ever non-z
On Mon, Apr 10, 2006 at 11:36:34AM +0100, Keir Fraser wrote:
> I'd rather define a function to fill in the entire structure in
> gnttab.h.
I hope that the attached patch is much more preferable
than the previous one.
I tested compilation and dom0 boot.
--
yamahata
# HG changeset patch
# User
Hi Tristan
Thanks for your comments
>From: Tristan Gingold
>Sent: 2006年4月10日 19:37
>Le Vendredi 07 Avril 2006 21:02, Xu, Anthony a écrit :
>> Hash vTLB is intended to address SMP scalability for large system.
>I don't really understand this.
>
>From my point of view, your patches add 3 changes:
Le Vendredi 07 Avril 2006 21:02, Xu, Anthony a écrit :
> Hash vTLB is intended to address SMP scalability for large system.
I don't really understand this.
From my point of view, your patches add 3 changes:
* VHPT is per VP (and not LP).
* Collision chains
* itc large pages correctly handled.
I w
Le Vendredi 07 Avril 2006 20:02, Magenheimer, Dan (HP Labs Fort Collins) a
écrit :
> > >individually. For example, if your TLB mapping fix solves
> > >the "gcc segmentation fault" issue, even if there is a
> > >performance hit, the fix should be accepted.
> >
> > I got domU performance data now,
On 10 Apr 2006, at 11:24, Isaku Yamahata wrote:
I attached an updated patch following to the comment.
The macro has a poor name (which is forgivable, since the name of the
field you're filling in has a poor name which we'll probably change).
It's also defined in (imo) the wrong place.
I'd
I attached an updated patch following to the comment.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID dc23c3042cdfa38c37ca60128eb13fb54973b739
# Parent 81bc9e9fb40ddd5c4366da8f7b667363005b1f92
make grant table map/unmap argument, host_addr, arch-apecific.
introduce an arch-
Hi,
Do you have any problems if you make all architectures use
this approach? It would be better to use the same approach.
> # HG changeset patch
> # User [EMAIL PROTECTED]
> # Node ID f490d7d1ecce78acc40dda7644e59e7840c68ef4
> # Parent 3434966aa3d1aca4c6f04323c9d2e900a1084417
> PageForeign() u
The following patch series are necessary for xen/ia64 VP model.
Although I tested only compiling and booting dom0 on xen/x86_32,
I believe the patches don't break existing xen/x86.
Xen/IA64 developers have been working on getting vnif, balloon driver
to work. The results of the effort are the ser
6/6
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 0ec28d25907df04890586a9ba8d4c0a593b37451
# Parent 6cb524702355fae2d2a324243cf2748e11a34725
This patch is for justifying the previous patch, page_to_bus.patch,
by showing how to allow auto translated mode domain to work as b
5/6
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 6cb524702355fae2d2a324243cf2748e11a34725
# Parent d5f57d15427027e5e824b9a274d1040a58f275f7
introduce page_to_bus() and use it in pci-dma-xen.c and swiotlb.c
On xen/ia64 with the P2M/VP model pseudo physical address(gpaddr)
4/6
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID d5f57d15427027e5e824b9a274d1040a58f275f7
# Parent f490d7d1ecce78acc40dda7644e59e7840c68ef4
grant table map/unmap use dev_bus_addr to pass pseudo physical address
to xen.
grant table map/unmap on Xen/x86 needs virtual addres
3/6
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID f490d7d1ecce78acc40dda7644e59e7840c68ef4
# Parent 3434966aa3d1aca4c6f04323c9d2e900a1084417
PageForeign() uses PG_arch_1. However Linux/ia64, Linux/ppc already use
the flag for their own purpose. So the flag can't be used.
T
2/6
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 3434966aa3d1aca4c6f04323c9d2e900a1084417
# Parent 03e1295121243a3ff53253b276e9b33030f0276f
change the type of grant_mapping_t::ref_and_flags from u16 to u32 for xen/ia64.
xen/x86 u16 grant_mapping_t::ref_and_flags can hand
1/6
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 03e1295121243a3ff53253b276e9b33030f0276f
# Parent 81bc9e9fb40ddd5c4366da8f7b667363005b1f92
change the type of grant_entry_t::frame from uint32_t to unsigned long.
active_grant_entry_t::frame is type of unsigned long.
grant_
46 matches
Mail list logo
