Dong, Eddie writes:
> I am not sure about the statement. Putting vTLB in physical VHPT side
> is mixing something, not only sharing. What I mean here is something
> like following pseudo code, (defenitely init code and many cleanup
> was not in this pseudo code).
Yes, mixing. I meant sharing is th
>> 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
Dong, Eddie writes:
> TLB. The issue in today's Xen/IA64 is
> that so called vTLB is not equal to real guest TLB. (guest TLB
> = vTR + vTLB + something in VHPT + something in machine TLB)
>
> If you want to rename vTLB to something else, I will vote for Yes.
Yea, vTLB should be renamed vTC.
> S
[EMAIL PROTECTED] writes:
> to be honest I have mixed feelings about your patch. I like it but I don't
> really understand its purpose. See my comment.
>
> I still think it would be nice if the vTLB were TR-mapped.
IMO, it is not worthwhile to map the vTLB on a TR.
I surely explained one of ad
[EMAIL PROTECTED] wrote:
> Hi Kouya,
>
> to be honest I have mixed feelings about your patch. I like it but I
> don't really understand its purpose. See my comment.
>
> I still think it would be nice if the vTLB were TR-mapped.
This is same with sharing vTLB/VHPT memory. Single TR
or double TR
Hi Kouya,
to be honest I have mixed feelings about your patch. I like it but I don't
really understand its purpose. See my comment.
I still think it would be nice if the vTLB were TR-mapped.
Quoting Kouya Shimura <[EMAIL PROTECTED]>:
> Dong, Eddie writes:
> > This can be simply solved by inc
Dong, Eddie writes:
> This can be simply solved by increasing vTLB size, or
> use same memory with VHPT.
The problem is, how much size is suitable?
There is a trade off. The larger size consumes a time for ptc.e
emulation and causes a serious slowdown for a Windows guest.
Currently vTLB size is
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
Oops, I did a little more cleanup.
Thanks,
Kouya
Signed-off-by: Kouya Shimura <[EMAIL PROTECTED]>
Alex Williamson writes:
>
> On Thu, 2008-02-28 at 17:17 +0900, Kouya Shimura wrote:
> > @@ -82,7 +68,6 @@ int init_domain_tlb(struct vcpu *v)
> > if (rc)
> > return rc;
> >
> > -
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.
With this patch, [id]tlb miss hanlder must distinguish a v
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
On Thu, 2008-02-28 at 17:17 +0900, Kouya Shimura wrote:
> @@ -82,7 +68,6 @@ int init_domain_tlb(struct vcpu *v)
> if (rc)
> return rc;
>
> -rc = thash_alloc(&(v->arch.vtlb), default_vtlb_sz, "vtlb");
> if (rc) {
> free_domain_vhpt(v);
> return rc;
The
12 matches
Mail list logo
