search for: gingold

Hi, xencomm is the ppc infrastructure to do hypercalls with guest physical addresses instead of virtual address. Because ia64 should also use physicall address, I think it''s better to re-use the ppc code and to put into common code. I''d propose to submit this patch is every part is OK (ie no NAK). This patch creates include/xen/xencomm_access.h which is to be included by

>From: Tristan Gingold [mailto:Tristan.Gingold@bull.net] >Sent: 2006年4月21日 15:26 >> > >> >See how we solve this on x86 near the top of do_boot_cpu() in >> >arch/x86/smpboot.c. Essentially we allocate extra idle domains on >> >demand to give us enough idle vcpus for one per physical...

>From: Tristan Gingold [mailto:Tristan.Gingold@bull.net] >Sent: 2006年4月21日 15:40 > >Le Vendredi 21 Avril 2006 09:28, Tian, Kevin a écrit : >> From: Tristan Gingold [mailto:Tristan.Gingold@bull.net] >> >> >Sent: 2006年4月21日 15:26 >> > >> >> >See how we solve this on x86...

Hi, on IA64 flushing the whole TLB is very expensive: this is a cpu tlb flush and clearing 16MB of memory (virtual tlb). However, flushing an address range is rather cheap. Flushing an address range on every processors is also cheap (no IPI). Unfortunatly Xen common code flushes the whole TLB after unmapping grant reference. Currently, this is not done on IA64 because domain_dirty_cpumask

(CCed to xen-devel for completeness. ;) On Wed, 2006-08-16 at 17:24 +0200, Tristan Gingold wrote: > I am porting xen-ppc''s xencomm to xen/ia64. > Currently on xen/ia64 copy_from/to_guest uses guest virtual address. This > works well as long as the virtual addresses are in the TLB. When not in TLB > (or vTLB) the hypercall can''t success without domain hel...

Hi, taking into account Hollis comments I now submit this patch. IA64 specific stuff will be posted to xen-ia64-unstable after merge. Tristan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...you define them in case of you? > - xen/hypercall.h (new) > - xen/multicall.h > - asm/multicall.h > - etc > > I think xen/hypercall.h is better. Why not. I send this mail to xen-devel, so that we can have official advices! > > Best regards, > Kan > > Tristan Gingold wrote: > >Le Mercredi 25 Janvier 2006 13:09, Masaki Kanno a 馗rit : > >> Hi, > >> > >> This patch added multicall hypercall. > >> The xm top command succeeded. > >> > >> Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com> > &...

Hi, for ia64, I''d like to add xc_domain_setdebugging() in the xenctrl API. This patch implements it and modifies xc_ptrace.c to use it. The rationnal is enabling debugging tool not based on the ptrace API. The ptrace API is based on Linux ptrace which (at least on ia64) doesn''t have many privilegied registers. I''d prefer this patch being integrated on

>From: Tristan Gingold >Sent: 2006年5月23日 15:30 > >Le Lundi 22 Mai 2006 17:44, Keir Fraser a écrit : >> On 22 May 2006, at 08:57, Tristan Gingold wrote: >> > this patch creates a new file: cpuhotplug.c. The content is the >xenbus >> > handler part of smpboot.c. The purpose is to be ab...

On Apr 6, 2010, at 1:10 AM, Tristan Gingold wrote: > > On Apr 3, 2010, at 2:36 PM, Russell Wallace wrote: > >> On Fri, Apr 2, 2010 at 6:17 PM, Chris Lattner <clattner at apple.com> wrote: >>> No, please don't. This is something we specifically do not want to support. The issue is not the parser, the iss...

Please pick up Tristan Gingold''s patch referenced below. The 2nd and 3rd parts build on top of it. http://lists.xensource.com/archives/html/xen-devel/2006-09/msg00120.html Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-dev...

Hi, this is almost an ia64 specific patch to xenperf. It makes xenperf output more understandable. On x86, it now displays hypercalls name. Tested on xen/ia64. Tristan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

On Apr 3, 2010, at 2:36 PM, Russell Wallace wrote: > On Fri, Apr 2, 2010 at 6:17 PM, Chris Lattner <clattner at apple.com> wrote: >> No, please don't. This is something we specifically do not want to support. The issue is not the parser, the issue is that struct field offsets are no longer constant in this model. > > What about declaring that pointers are always 64

This patch modifies the physinfo hcall to export NUMA CPU and Memory topology information. The new physinfo hcall is integrated into libxc and xend (xm info specifically). Included in this patch is a minor tweak to xm-test''s xm info testcase. The new fields in xm info are: nr_nodes : 4 mem_chunks : node0:0x0000000000000000-0x0000000190000000

On Fri, Apr 2, 2010 at 6:17 PM, Chris Lattner <clattner at apple.com> wrote: > No, please don't.  This is something we specifically do not want to support.  The issue is not the parser, the issue is that struct field offsets are no longer constant in this model. What about declaring that pointers are always 64 bits, for all purposes other than final code generation of actual pointer

...9;' command - it just didn''t occur to me at the time! Simon > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Akio Takebe > Sent: Thursday, August 03, 2006 8:57 AM > To: Tristan Gingold; John Levon; Keir Fraser > Cc: Muli Ben-Yehuda; Horms; Akio Takebe; xen-devel; Kouya Shimura > Subject: Re: [Patch][RFC] Support "xm dump" (is Re: [Xen-devel] Re: > [Patch]Enable "sysrq c" handler for domU coredump) > > Hi, all > > >> For example p...

...jp.fujitsu.com> + * Masaki Kanno <kanno.masaki at jp.fujitsu.com> + * Matt Chapman <matthewc at hp.com> + * Matthew Chapman <matthewc at hp.com> + * Samuel Thibault <samuel.thibault at eu.citrix.com> + * Tomonari Horikoshi <t.horikoshi at jp.fujitsu.com> + * Tristan Gingold <tgingold at free.fr> + * Tsunehisa Doi <Doi.Tsunehisa at jp.fujitsu.com> + * Yutaka Ezaki <yutaka.ezaki at jp.fujitsu.com> + * Zhang Xin <xing.z.zhang at intel.com> + * Zhang xiantao <xiantao.zhang at intel.com> + * dan.magenheimer at hp.com + * ian.pratt at cl.cam.ac...

...jp.fujitsu.com> + * Masaki Kanno <kanno.masaki at jp.fujitsu.com> + * Matt Chapman <matthewc at hp.com> + * Matthew Chapman <matthewc at hp.com> + * Samuel Thibault <samuel.thibault at eu.citrix.com> + * Tomonari Horikoshi <t.horikoshi at jp.fujitsu.com> + * Tristan Gingold <tgingold at free.fr> + * Tsunehisa Doi <Doi.Tsunehisa at jp.fujitsu.com> + * Yutaka Ezaki <yutaka.ezaki at jp.fujitsu.com> + * Zhang Xin <xing.z.zhang at intel.com> + * Zhang xiantao <xiantao.zhang at intel.com> + * dan.magenheimer at hp.com + * ian.pratt at cl.cam.ac...

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to