Jes Sorensen wrote:
> Dong, Eddie wrote:
>>> Rather than making these binary patches, why not make them fast
>>> syscalls and using a vdso page. Some of the priviledged instructions
>>> are simply reads and we could have that information in a read-only
>>>
>
> Rather than making these binary patches, why not make them fast
> syscalls and using a vdso page. Some of the priviledged instructions
> are simply reads and we could have that information in a read-only
> data page, so there is no need to do a context switch at all. Others
> could benefit fr
Use generic getreg/setreg pv_cpu_ops instead of
specific ones that may vary per hypervisor.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/arch/ia64/kernel/paravirt.c b/arch/ia64/kernel/paravirt.c
index 8e9fb96..072a1de 100644
--- a/arch/ia64/kernel/paravirt.c
++
Isaku Yamahata wrote:
> On Mon, Apr 07, 2008 at 05:47:38PM +0800, Dong, Eddie wrote:
>> Tony & all:
>> Recently we have completed the IVT.s pv_ops by using dual
>> compile, and also many cleanups to simplify the changes to upstream
>> code. All the C code to
Isaku Yamahata wrote:
> On Mon, Apr 07, 2008 at 05:25:54PM +0800, Dong, Eddie wrote:
>> In current approach, we have cpu ops like
>> eoi/set_tpr/get_tpr,/set_itm /set_kr0/set_kr2.../set_kr7 etc.
>> I think there is another simple alternative is to simply export
>>
Tony & all:
Recently we have completed the IVT.s pv_ops by using dual
compile, and also many cleanups to simplify the changes to upstream
code. All the C code touching privilege instruction is replaced with
indirect function call (will be binary patched to use direct function
call in future
In current approach, we have cpu ops like eoi/set_tpr/get_tpr,/set_itm
/set_kr0/set_kr2.../set_kr7 etc.
I think there is another simple alternative is to simply export
setreg/getreg
for cpu ops.
The benefit of this could be:
1: Simple in pv_ops I/F
2: hypervisor neutral. Today we
Isaku Yamahata wrote:
> Hi Eddie.
>
> I commited some clean ups based on your patch.
> Could you please review it?
>
It looks like you still prefer to use intermediate symbol
paravirt_/ia64_native_xxx to wrap ia64_xxx. In some sense, when
I saw many similar and bulk code in the patch, I fee
In current patch series, we have many definition:
+#define ia64_itci ia64_native_itci
+#define ia64_itcd ia64_native_itcd
+#define ia64_itri ia64_native_itri
+#define ia64_itrd ia64_native_itrd
+#define ia64_tpa
Isaku Yamahata wrote:
> On Wed, Apr 02, 2008 at 01:51:28PM +0800, Dong, Eddie wrote:
>> Current definition of intrinsic APIs seems to be too expansive, this
>> one
>>
>> give alternative way to do simply and reduce some changes.
>> If this applies, further simp
Current definition of intrinsic APIs seems to be too expansive, this one
give alternative way to do simply and reduce some changes.
If this applies, further simplification can be applied.
Thx, eddie
Simplify intrinsic API handling.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
dif
Isaku Yamahata wrote:
> On Fri, Mar 28, 2008 at 01:43:23PM +0800, Dong, Eddie wrote:
>
>>> Eventually those running_on_xen checks should be removed somehow.
>>> Are you just thinking that the multi compile with binary patching
>>> should be introduced after the fi
Isaku:
When looking at the new files in kernel & new directory, I am
wondering if we
can merge paravirt_core.c code into paravirt.c? The size of them are
very small
and meaning are similar, also X86 put in one file.
Another file is paravirt_entry.c, will paravirt_patch.c be much
ac
Isaku Yamahata wrote:
> Oh, I misunderstood your patch.
> I thought it just revert entry.S to original state. But it
> paravirtualized conver and rfi with running_on_xen check.
> Now I'm convinced that your patch works. Only one comment on
> the patch itself is,
> #ifdef CONFIG_XEN is necessary for
Isaku Yamahata wrote:
> I guess you just followed x86 way, but delaying until check_bug()
> is too late for IA64 case because of at least ia64_get_cpuid().
No. Binary patching is just optimization, while pv_ops hook
is installed at very beginning.
> At this moment I'm not sure how late binary pat
Isaku Yamahata wrote:
> arch/ia64/kernel/ivt.o is overwritten.
> Building again under arch/ia64/kernel would cause trouble.
> What do you think the following?
>
> ia64/pv_ops: complie paravirtualized assembly files into each pv dirs.
>
> compile ivt.S and switch_leave.S into each pv instanc dir.
Isaku Yamahata wrote:
> Hi Eddie.
>
> I looked into entry.S closely.
> Unfortunately I found that ia64_leave_syscall() and
> ia64_leave_kernel() includes invirtualizable instructions,
> cover instruction with psr.ic = 0 so that those paravirtualization
> is inevitable. (ia64_switch_to() doesn't ne
Isaku Yamahata wrote:
> On Thu, Mar 27, 2008 at 12:20:37PM +0800, Dong, Eddie wrote:
>
>>> - shuffle instructions of XEN_BSW_1 and xen DO_XEN_MIN().
>>> Is this for producing better bundles? Please ellaborate on this.
>>> If so, I'll take as another patc
It seems some APIs in that file is dead code, this one is to
remove dead code or dom0 only code?
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/arch/ia64/xen/Makefile b/arch/ia64/xen/Makefile
index 605b757..dc8fee6 100644
--- a/arch/ia64/xen/Makefile
+++ b/arch/ia64/xe
Most hypercall are identical in source code, using a common
MACRO to define 0/1/2 parameter(s) hypercall is much simple.
arch/ia64/xen/hypercall.S | 154
+-
include/asm-ia64/xen/privop.h | 26 ---
2 files changed, 51 insertions(+), 129 deletions(
Isaku Yamahata wrote:
> Hi Eddie.
> The attached patches does many things. Could you explain?
>
> - convert cover argument in SAVE_MIN_WITH_COVER(_R19) into COVER.
> This seems correct. I'll take this part.
>
> - convert __COVER argument into COVER.
> Using conflicting argument is a bad pract
Jeremy Fitzhardinge wrote:
> Dong, Eddie wrote:
>> Jeremy/Andrew:
>>
>> Isaku Yamahata, I and some other IA64/Xen community memebers are
>>
>> working together to enable pv_ops for IA64 Linux. This patch is a
>> preparation to move common arch/x86/x
arch/ia64/kernel/paravirt.c |8 +++-
arch/ia64/kernel/paravirt_core.c | 17 ++---
arch/ia64/kernel/paravirt_entry.c |3 ++-
arch/ia64/kernel/setup.c |3 +++
arch/ia64/xen/paravirt_xen.c |8 +---
arch/ia64/xen/xen_pv_ops.c|4 ++
Currently, paravirt_init_IRQ_early is used to register
IA64_IPI_RESCHEDULE/IA64_IPI_LOCAL_TLB_FLUSH for different
hypervisor/native. It seems not strightforward from the name, how about
something like:
pv_irq_ops.register_ipi ?
We can let include IA64_IPI_VECTOR register too.
I am
commit d9c6c77dbb20cd5cc9ffbbe8e2398eb737a83162
Author: root <[EMAIL PROTECTED]>
Date: Wed Mar 26 14:14:31 2008 +0800
Remove paravirt_init_IRQ_late since it is never activated.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/arch/ia64/kernel/irq_ia64.c b/arch/ia6
Dong, Eddie wrote:
> Jeremy/Andrew:
>
> Isaku Yamahata, I and some other IA64/Xen community memebers are
>
> working together to enable pv_ops for IA64 Linux. This patch is a
> preparation to
> move common arch/x86/xen/events.c to drivers/xen (contents are
> iden
Akio Takebe wrote:
> Hi, Isaku and all
>
> I'd like to start pv_ops work.
> I'm not familiar with git command.
>
> I did "git clone" Isaku's git tree, but I cannot download it.
> (I can download Xiantao's kvm-ia64 git tree.)
> Did I have some mistakes? And can I use git protocol instead of http?
Akio Takebe wrote:
> Hi, Eddie
>
>> diff --git a/arch/ia64/kernel/ivt.S b/arch/ia64/kernel/ivt.S
>> index f2306ae..d516bf4 100644
>> --- a/arch/ia64/kernel/ivt.S
>> +++ b/arch/ia64/kernel/ivt.S
>> @@ -19,6 +19,7 @@
>> * Copyright (c) 2008 Isaku Yamahata
>> *VA Linux Systems
Replace all sensitive instructions in dual compile IVT.s.
Now the total change against upstream is:
89 files changed, 8857 insertions(+), 1059 deletions(-)
All in one patch file size is 11643 lines.
If we can seperate those common file movement from arch/x86/xen
to driver/xen, additional 1.2-1.
The MACRO parameter COVER in DO_SAVE_MIN won't
be replaced by COVER macro in inst.h since it is already
replaced when compiler extend SAVE_MIN_WITH_COVER
macro etc.
Thanks, eddie
Fix DO_SAVE_MIN macro typo, and move some
instructions to make bundle compact.
Signed-off-by: Yaozu
Jeremy & all:
Current xen kernel codes are in arch/x86/xen, but xen dynamic
irqchip (events.c) are common for other architectures such as IA64. We
are in progress with enabling pv_ops for IA64 now and want to reuse same
code, do we need to move the code to some place common? suggestions?
Dong, Eddie wrote:
> Alex/Isaku:
> Current the make file is to compile additional ivt.S at
> kernel/., another approach is to compile in xen/..
> The later one has following benfit:
> 1: Easy to read for Makefile and easy to extend for more
> hypervisors.
>
Alex/Isaku:
Current the make file is to compile additional ivt.S at
kernel/., another approach is to compile in xen/..
The later one has following benfit:
1: Easy to read for Makefile and easy to extend for more
hypervisors.
2: Xen specific ministate.h can be in arch
Followup patch to delete dead file then.
Thanks, eddie
entry32.patch
Description: entry32.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Either are fine.
-Original Message-
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
Sent: 2008年3月19日 10:45
To: Dong, Eddie
Cc: Alex Williamson; xen-ia64-devel@lists.xensource.com
Subject: Re: simplify hw_irq.h
Hi Eddie.
Thank you for the patches.
ia64_vector is for iosapic redirect
Alex Williamson wrote:
> On Tue, 2008-03-18 at 22:18 +0800, Dong, Eddie wrote:
>>>> How about just simply use CONFIG_PARAVIRT ?
>>>
>>>Then how do you specify that you want a kernel built with Xen
>>> support, but not KVM?
>>>
>>
>
CONFIG_XEN_IA64_EXPOSE_P2M could be dropped for 1st domU only patch to
achieve small patch size, since it is a kind of performance patch.
Thx, eddie
x4
Description: x4
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xens
Alex Williamson wrote:
> On Tue, 2008-03-18 at 22:19 +0800, Dong, Eddie wrote:
>> Yes, but running_on_xen is already there.
>
>Will it be there if we only have a kernel compiled with PV KVM
> support? Are we going to stub out any *_xen_* function/macro in that
> case?
&
Xen specific directories are only compiled with Xen, keeping CONFIG_XEN
in each file is redudant.
diff --git a/arch/ia64/xen/xen_pv_ops.c b/arch/ia64/xen/xen_pv_ops.c
index 93a5c64..0c978e8 100644
--- a/arch/ia64/xen/xen_pv_ops.c
+++ b/arch/ia64/xen/xen_pv_ops.c
@@ -210,10 +210,8 @@ static void
>> How about just simply use CONFIG_PARAVIRT ?
>
>Then how do you specify that you want a kernel built with Xen
> support, but not KVM?
>
Mmm, this is kind of what level of detail do we want user to choose.
Given that RHEL want one image, so this sub-option is just for
in house development
Yes, but running_on_xen is already there.
Alex Williamson wrote:
> On Tue, 2008-03-18 at 21:51 +0800, Dong, Eddie wrote:
>> Following CONFIG_XEN is kind of historic issue, with CONFIG_PARAVIRT,
>> those code should be always enabled, so replacing with
>> CONFIG_PARA
Following CONFIG_XEN is kind of historic issue, with CONFIG_PARAVIRT,
those code should be always enabled, so replacing with CONFIG_PARAVIRT
makes more sense.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/arch/ia64/kernel/Makefile b/arch/ia64/kernel/Makefile
index a80dd3f.
Alex Williamson wrote:
> Hi Isaku,
>
>Here's some cleanup to arch/ia64/kernel/time.c. I removed
> time_resume() since it's not called from anywhere. I think this file
> still needs some work; any PV guest is going to need something like
> this, so it would be nice to isolate the Xen specific
Alex Williamson wrote:
> On Tue, 2008-03-18 at 11:36 +0800, Dong, Eddie wrote:
>>>
>>>I think CONFIG_XEN might become something like
>>> CONFIG_PARAVIRT_XEN, which will be dependent on CONFIG_PARAVIRT.
>>> There might also be CONFIG_PARAVIRT_LGUEST, C
Alex Williamson wrote:
> On Mon, 2008-03-17 at 14:07 +0800, Dong, Eddie wrote:
>>
>> Something I want to get clarified first, eventually with pv_ops
>> patch series get in, RH eventually will only compile to get one
>> image to run on different platforms including xen
>> Commit a07b265c618c279a84bac8f75f5acba1c1646200 is quit intrusive,
>> it removed code from entry.S to a new file switch_entry.S and create
>> 1000 lines of patch.
>>
>> At least we stay in original file, not?
>
> At least xen/ia64 needs to paravirtualize ia64_swtich_to,
I did a scan on Alex
Alex Williamson wrote:
> On Fri, 2008-03-14 at 17:19 +0800, Dong, Eddie wrote:
>> Oh, either are OK, just make sure we are in same page. Pleae
>> keep this here. But we need to make sure generic_defconfig can
>> include Xen machine vector in current case. Some Makefile/so
Isaku/Alex:
There is a new file called kernel/inst_native.h to define those
pv MACROs for native. I would suggest we do following changes:
1: Move it to public head files such as include/asm-ia64 at
least since some other files will use it too.
2: Further thinking is that h
Isaku/Alex:
There are some some certain features that target dom0 or for
some extended domU features such as EXEC support etc, I would suggest we
drop it temporary after some basic domU code get in. If this is true,
then patch like following can be dropped, also many other files are
similar
Isaku Yamahata wrote:
> Hi Eddie.
> Thank you for your patch.
> the change is already isolated as the commit of
> d81f732b0d57371bfc220b1a1027ab18ea9a5265.
> So what we need to do is just dropping the change set.
> The same would apply to the gate page paravirtualization change set.
> I'll take car
Isaku Yamahata wrote:
> On Fri, Mar 14, 2008 at 03:39:15PM +0800, Dong, Eddie wrote:
>> Isaku:
>> Targeting the patchset or git tree
>>
http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git/,
>> I got some questions:
>
> Thank you for comments
CONFIG_XEN needs to be gradually removed per discussion since pv_ops
include this concept.
Due to this, we defer the fsys.S changes for some time later to use
indirect function call.
Temporay undo it for now.
Thanks, eddie
commit a882270f415e717a3694f2762f348ab285fb55ce
Author: root <[EMAIL PR
Isaku:
Targeting the patchset or git tree
http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git/,
I got some questions:
1: I saw some config options such as:
CONFIG_PARAVIRT
CONFIG_PARAVIRT_ALT
CONFIG_PARAVIRT_ENTRY
CONFIG_PARAVIRT_NOP_B_PATCH
CONFIG_PARAVIRT_GUEST
Tristan Gingold wrote:
> Hi,
>
> just a point about call convention: I don't think switching to PAL
> static convention is a good idea as it doesn't work well with xen
> hyperprivop because of banked registers.
>
> Tristan.
Tristan:
This is for pv_ops interface calling convention, not hy
y few place which may use a
formal pv_ops for ASM code which imply the calling convention. All IVT/gate
table/page doesn't have this issue.
Thanks, eddie
-Original Message-
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2008年3月11日 17:24
To: Dong, Eddie
Cc: Alex Williamson
> I don't have any architecture specific examples off the top of my
> head, but how about skipping serial port detection on dom0? It's
> rather Xen specific and we haven't yet come up with a way to hide
> Xen's UART (ioport & mmio) from dom0. KVM/Lguest wouldn't care about
> this, so it may no
Alex Williamson wrote:
> On Mon, 2008-03-10 at 13:56 +0800, Dong, Eddie wrote:
>> Alex & all:
>> I exchanged some ideas with Isaku to discuss the gap and status
>> of pv_ops support in IA64, Isaku did a lot of work toward pv_ops
>> since his previous forward
It looks like current VMX VHPT implementation didn't remove a collision
chain node when it beccomes invalid. Not sure what is the purpose, but
at least it reduces the free collision chain buffer size and makes chain
walk longer.
Any special reasons? I remember long time ago, the invalid entry is
r
>> Limiting the entry to be not moved to VHPT head could solve this
>> issue but again the code will be complicated.
>>
>> Sharing VTLB/VHPT memory could be simply used here, and the patch
>> will be more smaller and simple IMO.
>My concept is just sharing vTLB/VHPT memory.
>As long as sharing
ry. Single TR
or double TR (your case) can solve problem both.
>
>
> Quoting Kouya Shimura <[EMAIL PROTECTED]>:
>
>> Dong, Eddie writes:
>>> This can be simply solved by increasing vTLB size, or
>>> use same memory with VHPT.
>>
>> The pr
Kouya Shimura wrote:
> Hi Eddie,
>
> First of all, I don't touch a vTR at all.
>
> And then, from the HW point of view, nothing is changed.
> Because a vTLB is not located in VHPT area where the hardware
> page walker can access. It's located only in collision chain area.
Thanks for point out, i
Isaku Yamahata wrote:
> Hi. Thank you for comments on asm code paravirtualization.
> Its direction is getting clear. Although it hasn't been finished yet,
> I'd like to start discussion on ia64 intrinsics paravirtualization.
> This patch set is just for discussion so that it is a subset of
> xen Li
Kouya Shimura wrote:
> Hi,
>
> Currently a HVM domain has vtlb and vhpt individually.
> This patch unifies them. A vtlb entry is recorded in
> vhpt collision chain area.
Mmmm, I am not sure if it is correct in theory. If we put
vTLB in VHPT, which means hash/tag can be used to
uniquely identify a
> IA64 pv_ops frame work doesn't exist yet so that xen code does
> in order to boot on both native and xen for now.
> I expect those check will be eliminated during developing ia64 pv_ops.
Qing He & I am working on the pv_ops framework, hopefully we can get
a draft soon :)
Eddie
___
Keith Owens wrote:
> Isaku Yamahata (on Mon, 25 Feb 2008 12:16:42 +0900) wrote:
>> Hi. The patch I send before was too large so that it was dropped from
>> the maling list. I'm sending again with smaller size.
>> This patch set is the xen paravirtualization of hand written assenbly
>> code. And I e
Isaku Yamahata wrote:
>> 2: Same IVT source code, but dual/mulitple compile to generate
>> dual/multiple IVT table. I.e. we replace those primitive ops
>> (sensitive instructions) with a MACRO which uses compile option for
>> different hypervisor type. The pseudo code of the MAC
Robin Holt wrote:
> those should be discussed here. Also, could you repost the patches?
The work is just started, so sorry we don't have patches in hand right
now.
But we can provide some example code for better reference.
>
> On a different note, I am willingly and woefully unaware of what the
Hi, Tony & all:
Recently Xen-IA64 community is considering to add paravirt_ops
support to keep sync with X86 and reduce maintenance effort. With
pv_ops, sensitive instructions or some high level primitive
functionalities (such as MMU ops) are replaced with pv_ops which is a
function table c
Isaku Yamahata wrote:
> Dong, Eddie wrote:
>> I guess we are talking in different angle which hide the real
>> issues. We
>> have multiple alternaitves:
>> 1: pv_ops
>> 2: pv_ops + binary patching to convert those indirect function call
>> to direct func
Alex Williamson wrote:
> On Fri, 2008-02-15 at 00:43 +0800, Dong, Eddie wrote:
>> I agree with your catagory, but I think #C is the 1st challenge we
>> need to address for now. #A could be a future task for performance
>> later after pv_ops functionality is completed
Great progress!
>
> Eddie, I haven't forgotten your discussion.
> I think it is necessary to get linux-ia64 people involved for
> the discussion. The concrete patch is needed.
Yes, so are you planing to push pv_ops based solution or
binary patching based solution? My basic understanding to
redh
Dong, Eddie wrote:
> All:
> If we use single IVT table, the pv_ops code will look like:
>
> ALT0:
> breg0 = pv_ops base
> breg0 += offset for this pv_ops
> breg1 = return address;
> br breg0. /* pv_ops clobbered breg0/breg1 */
All:
If we use single IVT table, the pv_ops code will look like:
ALT0:
breg0 = pv_ops base
breg0 += offset for this pv_ops
breg1 = return address;
br breg0. /* pv_ops clobbered breg0/breg1 */
That means we have to use 2 BR clobber regi
Isaku Yamahata wrote:
> On Tue, Feb 05, 2008 at 10:17:10PM +0800, Dong, Eddie wrote:
>> 1: The coding style is not as good as original IVT code.
>
> I have to agree with you here.
>
>
>> For example:
>> #ifdef CONFIG_XEN
>>
Isaku Yamahata wrote:
>> Dual compile could be a good approach. Another alternative will be
>> X86 pv_ops like dynamic binary patching per compile time hints. The
>> later method also uses macro for those different path, but this
>> macro will generate a special section including the information f
>
> The kernel guarantees applications only see time move forward, even
> across multiple CPUs. See:
>
> kernel/timer.c:time_interpolator_get_counter()
>
> We never return a time before last_cycle unless booted with the
> "nojitter" options.
>
Echo from me too.
I was told some time ago, t
Kouya Shimura wrote:
> Dong, Eddie writes:
>> 3: irq chip paravirt_ops, xen irq chip or vSAPIC?
>
> Is xen irqchip really necessary?
X86 side already pushed the xen irq chip into upstream, so I think
it should be easy to do same thing in IPF side.
>
> In current
Yang, Fred wrote:
> Alex Williamson wrote:
>> On Mon, 2008-02-04 at 09:53 +0800, Dong, Eddie wrote:
>>> Yang, Fred wrote:
>>>> Dong, Eddie wrote:
>>>>> Re-post it to warmup discussion in case people can't read PPT
>>>>> format,
>&
Alex Williamson wrote:
> On Fri, 2008-02-01 at 13:16 +0800, Dong, Eddie wrote:
>> The following code is not used anymore, and I think it is also a
>> legacy issue when people are debugging on SKI simulator.
>> Should we simplify it?
>> thx, eddie
>
>Yes, I
Yang, Fred wrote:
> Dong, Eddie wrote:
>> Re-post it to warmup discussion in case people can't read PPT format,
>
> IVT is very performance sensitive for the native Linux, how about
> dual IVT tables alternative for CPU virtualization? It would need
> maintainance e
Akio Takebe wrote:
> Hi, Xiantao and all
>
>> Akio Takebe wrote:
>>> Hi, Eddie and Kaz
>>>
I did a quick grep and find MINSTATE_PHYS is never defined in
xenlinux. Xen mca code did. Anything missed?
>>> The minstate.h is a little old, it seems to be around linux-2.6.9.
>>> Current
The following code is not used anymore, and I think it is also a legacy
issue when people are debugging on SKI simulator.
Should we simplify it?
thx, eddie
diff -r 0e62beb4c36a arch/ia64/xen/Makefile
--- a/arch/ia64/xen/MakefileFri Feb 01 09:33:32 2008 +0800
+++ b/arch/ia64/xen/MakefileF
I did a quick grep and find MINSTATE_PHYS is never defined in xenlinux.
Xen mca code did. Anything missed?
diff -r 71a415f9179b arch/ia64/xen/xenminstate.h
--- a/arch/ia64/xen/xenminstate.h Fri Jan 18 14:20:59 2008 -0700
+++ b/arch/ia64/xen/xenminstate.h Thu Jan 31 15:08:42 2008 +080
Isaku Yamahata wrote:
> On Thu, Jan 31, 2008 at 08:21:51AM +0800, Dong, Eddie wrote:
>> Alex & All:
>
> Hi Eddie.
> At first I'd like to make it clear. The goal is to merge
> xenLinux/ia64 modification into upstream kenrel. Hence reduce
> maintenane cost etc...
Kouya Shimura wrote:
> [EMAIL PROTECTED] writes:
>>> Do we have checks when inserting guest TLB for PV dom? Seems not,
>>
>> Yes, we do. See vcpu.c:check_xen_space_overlap
>
> It's only for xen area (region 7). domU can use full 60 bit VA on
> other region in spite of IMPL_VA_MSB = 50.
Yes, S
ddress except xen area.
> Ideally xen should check it and reflect the unimplemented address
> fault to the guest. But it sounds overkill.
>
> Isaku Yamahata writes:
>> On Thu, Jan 24, 2008 at 09:28:39AM +0800, Dong, Eddie wrote:
>>> Alex & All:
>>> Firs
Alex & All:
First of all, pls forgive me that I was out of Xen/IA64 for quit
a long time, and I didn't fully catch up yet now.
In the very beginning day of Xen/IA64, I remembered the address
isolation between guest (domU) & hypervisor is not solved though guest
PAL can provide less
[EMAIL PROTECTED] wrote:
> Quoting "Dong, Eddie" <[EMAIL PROTECTED]>:
>
>> [EMAIL PROTECTED] wrote:
>>> Quoting "Dong, Eddie" <[EMAIL PROTECTED]>:
>>>> Not sure if anybody ever tried to run Xen/IA64 VMM in Xen/IA64 HVM
>
[EMAIL PROTECTED] wrote:
> Quoting "Dong, Eddie" <[EMAIL PROTECTED]>:
>> Not sure if anybody ever tried to run Xen/IA64 VMM in Xen/IA64 HVM
>> guest? It may not be already there, but looks like not that far.
>
> I tried in the past, but it doesn't work
Xu, Anthony wrote:
> Jarod Wilson wrote:
>> Alex Williamson wrote:
>>> I would expect
>>> RHEL5.x will always support a PV dom0 and not require VT processors
>>> for Xen.
>>
>> Absolutely. And as I mentioned, since RHEL5 supports both PV and HVM
>> guests, we're pretty well committed to whatever s
ce in
1-2 percent should be a second level consideration for now.
Thanks very much!
Eddie
Tristan Gingold wrote:
> Le Mercredi 12 Avril 2006 16:51, Dong, Eddie a écrit :
>> Tristan Gingold wrote:
>> At every tlb miss time, you can get guest translation from software
>> TLB (not
Tristan Gingold wrote:
>>
>> Just make sure I am understanding correctly. With the help of
>> software TLB for guest huge translation, you have the flexibility to
>> either breakdown it into smaller ones to VHPT for all entries at a
>> time, or you can do one at a time. Defenitely several at a tim
Tristan Gingold wrote:
> Le Mercredi 12 Avril 2006 10:57, Dong, Eddie a écrit :
>> Tristan:
>> You are probably avocating for the flexibility of hash TLB too from
>> the issue :-) Yes, when multiple TLBs are supported, i.e. hash TLB
>> here, those big guest page t
Tristan:
You are probably avocating for the flexibility of hash TLB too from the
issue :-)
Yes, when multiple TLBs are supported, i.e. hash TLB here, those big
guest page translations can be put into software TLB using gmfn (leave to
future tuning). When it is inserted into machi
Congratulations!
That is why Kevin and I advocated many times before to suggest p2m
translation (p!=m) :-)
Can we also share the free beer?
Eddie
Magenheimer, Dan (HP Labs Fort Collins) wrote:
> I was also able to get networking working with Isaku's patches
> and Alex's. Hooray! For the last ei
Alex, Dan & all:
I believe this patch should be in shortly. The reason is that:
1: We don't want to have different memory management approach
between VTI & non-VTI domain. Otherwise every effort like smp.g need to
be double implemented in both VTI and non-VTI. People will soon ask e
All:
This is the draft design of the IRQ virtualization, comments are
appreciated.
Thx,eddie
Xen/IA64 interrupt virtualization
* Introduction
This document targets xen/ia64 developers, providing an design overview of
interrupt virtualization. How the guest IOSAPIC looks l
;
> http://lists.xensource.com/archives/html/xen-ia64-devel/2005-11/msg00282.html
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Xu,
>> Anthony Sent: Monday, March 13, 2006 6:37 PM
>> To: Dong, Eddie; Tian, Kevin;
Really a good job!
A minor suggestion for next in my mind is that we may add a simple
COMPILE option in Makefile or some .h file to be able to choice 1/3 byte
swap or 1/2 byte swap. People has some thoughts that 1/2 byte swap may
have better hash locality.
Eddie.
Tristan Gingold wrote:
> Le Jeudi 09 Mars 2006 21:02, Tian, Kevin a écrit :
>> Anyway, good discussion by far though still some way to go for
>> consensus. :-)
>>
>> Maybe we want to look at this from another way - fairness. [...]
>> Regarding current model, there seems to be an issue about fairn
1 - 100 of 144 matches
Mail list logo
