Xen devel - Jan 2008 - [PATCH][RFC]Provide fast write emulation path to release shadow lock

Provide fast write emulation path to release shadow lock.

Basically we can consider shadow fault logic into two parts,
with 1st part to cover logistic work like validating guest
page table or fix shadow table, and the 2nd part for write
emulation.

However there''s one scenario we can optimize to skip the
1st part. For previous successfully emulated virtual frame,
it''s very likely approaching at write emulation logic again
if next adjacent shadow fault is hitting same virtual frame.
It''s wasteful to re-walk 1st part which is already covered
by last shadow fault. In this case, actually we can jump to
emulation code early, without any lock acquisition until
final shadow validation for write emulation. By perfc counts
on 64bit SMP HVM guest, 89% of total shadow write emulation
are observed falling into this fast path when doing kernel
build in guest.

We also did series of tests on 32/32pae/32e: (host is 32e)
                   32       32pae       32e
----Linux----
kernel build   +1%    +0.86%    +1.9%
Specjbb        +0.9% +1.61%    +0.32%

----XP----
Sysbench     N/A     -0.05%     -0.32%(*)

* Sysbench score is not very stable on 32e guest, with up
to 6% variation observed in 5 rounds running. 32pae is
stable. 32 XP image was unfortunately corrupted at test 
cycle, so not test yet. Don''t want to hold here from getting
early comments. :-)

I thought the performance gain should be straightforward
with this patch, and thus would like to know comment
like:
	- Is it a right direction?
	- Is there anything wrong or missed in patch?
	- Any more benchmarks should we test?

Signed-off-by Kevin Tian <kevin.tian@intel.com>

Thanks,
Kevin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 10:20 +0800 on 22 Jan (1200997253), Tian, Kevin
wrote:
> We also did series of tests on 32/32pae/32e: (host is 32e)
>                    32       32pae       32e
> ----Linux----
> kernel build   +1%    +0.86%    +1.9%
> Specjbb        +0.9% +1.61%    +0.32%
> 
> ----XP----
> Sysbench     N/A     -0.05%     -0.32%(*)
> 
> * Sysbench score is not very stable on 32e guest, with up
> to 6% variation observed in 5 rounds running. 32pae is
> stable. 32 XP image was unfortunately corrupted at test 
> cycle, so not test yet. Don''t want to hold here from getting
> early comments. :-)
> 
> I thought the performance gain should be straightforward
> with this patch, and thus would like to know comment
> like:
> 	- Is it a right direction?
Looks good to me! 
> 	- Is there anything wrong or missed in patch?
Nothing fundamental that I can see by reading through it.  One thing
I''d
change is to avoid introducing "vfn": a virtual address >>
PAGE_SIZE is
just a "page number".
> 	- Any more benchmarks should we test?
Anything and everything. :)  Specially multi-vcpu mixed operations
(e.g. kernel compile + ltp + network traffic) while doing live migrate.
Even when they look as clean as this one, changes in the shadow fault
handler tend to chase out implicit/forgotten assumptions.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Tim Deegan [mailto:Tim.Deegan@citrix.com] 
>Sent: 2008年1月22日 17:26
>
>At 10:20 +0800 on 22 Jan (1200997253), Tian, Kevin wrote:
>> We also did series of tests on 32/32pae/32e: (host is 32e)
>>                    32       32pae       32e
>> ----Linux----
>> kernel build   +1%    +0.86%    +1.9%
>> Specjbb        +0.9% +1.61%    +0.32%
>> 
>> ----XP----
>> Sysbench     N/A     -0.05%     -0.32%(*)
>> 
>> * Sysbench score is not very stable on 32e guest, with up
>> to 6% variation observed in 5 rounds running. 32pae is
>> stable. 32 XP image was unfortunately corrupted at test 
>> cycle, so not test yet. Don''t want to hold here from getting
>> early comments. :-)
>> 
>> I thought the performance gain should be straightforward
>> with this patch, and thus would like to know comment
>> like:
>> 	- Is it a right direction?
>
>Looks good to me! 
>
>> 	- Is there anything wrong or missed in patch?
>
>Nothing fundamental that I can see by reading through it.  One 
>thing I''d
>change is to avoid introducing "vfn": a virtual address >>
PAGE_SIZE is
>just a "page number".
OK.
>
>> 	- Any more benchmarks should we test?
>
>Anything and everything. :)  Specially multi-vcpu mixed operations
>(e.g. kernel compile + ltp + network traffic) while doing live migrate.
>Even when they look as clean as this one, changes in the shadow fault
>handler tend to chase out implicit/forgotten assumptions.
>
Agree. I asked the question because the combinations are really too many
and usually we try those tests. So for the case you mentioned when doing
live migrate, can I consider the stability/correctness is the major test goal
since individual score may vary a lot in such complex environment?

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 18:01 +0800 on 22 Jan (1201024893), Tian, Kevin
wrote:
> Agree. I asked the question because the combinations are really too many
> and usually we try those tests. So for the case you mentioned when doing
> live migrate, can I consider the stability/correctness is the major test
goal
> since individual score may vary a lot in such complex environment?
Absolutely. 

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Tim Deegan [mailto:Tim.Deegan@citrix.com] 
>Sent: 2008年1月22日 18:07
>
>At 18:01 +0800 on 22 Jan (1201024893), Tian, Kevin wrote:
>> Agree. I asked the question because the combinations are 
>really too many
>> and usually we try those tests. So for the case you 
>mentioned when doing
>> live migrate, can I consider the stability/correctness is 
>the major test goal
>> since individual score may vary a lot in such complex environment?
>
>Absolutely. 
>
>Tim.
>
OK, thanks for your comment and I''ll do more stability test
before next update. :-)

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Tim and Kevin,
    I did some stability test with and without Kevin''s patch: 

First guest (Linux):  kernel build;
Second guest (Linux): network copy;
Third guest (Windows): Sysmark 2007;

In dom0, I did local migration to the three guest.

But I found that even without Kevin''s patch, the guest would be blue
screen in Windows or print some call trace in Linux guest. Have you seen this
issue before? Thanks!

Best Regards,
Xu Dongxiao

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Tim Deegan
Sent: 2008年1月22日 17:26
To: Tian, Kevin
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Re: [PATCH][RFC]Provide fast write emulation path torelease
shadow lock

At 10:20 +0800 on 22 Jan (1200997253), Tian, Kevin
wrote:
> We also did series of tests on 32/32pae/32e: (host is 32e)
>                    32       32pae       32e
> ----Linux----
> kernel build   +1%    +0.86%    +1.9%
> Specjbb        +0.9% +1.61%    +0.32%
> 
> ----XP----
> Sysbench     N/A     -0.05%     -0.32%(*)
> 
> * Sysbench score is not very stable on 32e guest, with up
> to 6% variation observed in 5 rounds running. 32pae is
> stable. 32 XP image was unfortunately corrupted at test 
> cycle, so not test yet. Don''t want to hold here from getting
> early comments. :-)
> 
> I thought the performance gain should be straightforward
> with this patch, and thus would like to know comment
> like:
> 	- Is it a right direction?
Looks good to me! 
> 	- Is there anything wrong or missed in patch?
Nothing fundamental that I can see by reading through it.  One thing
I''d
change is to avoid introducing "vfn": a virtual address >>
PAGE_SIZE is
just a "page number".
> 	- Any more benchmarks should we test?
Anything and everything. :)  Specially multi-vcpu mixed operations
(e.g. kernel compile + ltp + network traffic) while doing live migrate.
Even when they look as clean as this one, changes in the shadow fault
handler tend to chase out implicit/forgotten assumptions.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

So Tim, can you help see whether our test approach is 
wrong or it''s the fact with existing today''s code? Or you 
may suggest some scenarios you''re sure working with 
latest logic and then we can reproduce as comparison...

Thanks,
Kevin
>From: Xu, Dongxiao 
>Sent: 2008年1月25日 9:41
>
>Hi, Tim and Kevin,
>    I did some stability test with and without Kevin''s patch: 
>
>First guest (Linux):  kernel build;
>Second guest (Linux): network copy;
>Third guest (Windows): Sysmark 2007;
>
>In dom0, I did local migration to the three guest.
>
>But I found that even without Kevin''s patch, the guest would 
>be blue screen in Windows or print some call trace in Linux 
>guest. Have you seen this issue before? Thanks!
>
>Best Regards,
>Xu Dongxiao
>
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com 
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Tim Deegan
>Sent: 2008年1月22日 17:26
>To: Tian, Kevin
>Cc: xen-devel@lists.xensource.com
>Subject: [Xen-devel] Re: [PATCH][RFC]Provide fast write 
>emulation path torelease shadow lock
>
>At 10:20 +0800 on 22 Jan (1200997253), Tian, Kevin wrote:
>> We also did series of tests on 32/32pae/32e: (host is 32e)
>>                    32       32pae       32e
>> ----Linux----
>> kernel build   +1%    +0.86%    +1.9%
>> Specjbb        +0.9% +1.61%    +0.32%
>> 
>> ----XP----
>> Sysbench     N/A     -0.05%     -0.32%(*)
>> 
>> * Sysbench score is not very stable on 32e guest, with up
>> to 6% variation observed in 5 rounds running. 32pae is
>> stable. 32 XP image was unfortunately corrupted at test 
>> cycle, so not test yet. Don''t want to hold here from getting
>> early comments. :-)
>> 
>> I thought the performance gain should be straightforward
>> with this patch, and thus would like to know comment
>> like:
>> 	- Is it a right direction?
>
>Looks good to me! 
>
>> 	- Is there anything wrong or missed in patch?
>
>Nothing fundamental that I can see by reading through it.  One 
>thing I''d
>change is to avoid introducing "vfn": a virtual address >>
PAGE_SIZE is
>just a "page number".
>
>> 	- Any more benchmarks should we test?
>
>Anything and everything. :)  Specially multi-vcpu mixed operations
>(e.g. kernel compile + ltp + network traffic) while doing live migrate.
>Even when they look as clean as this one, changes in the shadow fault
>handler tend to chase out implicit/forgotten assumptions.
>
>Cheers,
>
>Tim.
>
>-- 
>Tim Deegan <Tim.Deegan@citrix.com>
>Principal Software Engineer, Citrix Systems (R&D) Ltd.
>[Company #02300071, SL9 0DZ, UK.]
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

At 09:41 +0800 on 25 Jan (1201254064), Xu, Dongxiao
wrote:
> But I found that even without Kevin''s patch, the guest would be
blue
> screen in Windows or print some call trace in Linux guest. Have you
> seen this issue before? Thanks!
Can you try building Xen with "vmxassist=y" on the make command-line?

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Tim and Kevin,
    I used the changeset 16704 to take the stability test, and at that
changeset, vmxassist=y is the default. Later I used the Xen3.2 test tree to have
a test, it met the same issue, that is, windows guest would be blue screen, and
linux guest would pop up some call trace. Also Dom0 will pop up some call trace
too. My test environment is

First guest (Linux):  kernel build;
Second guest (Linux): network copy;
Third guest (Windows): Sysmark 2007;

In dom0, I did local migration to the three guest.

Tim, could you tell me what''s the test case and test environment
(changeset) when you take the stability test? Then I may use your environment to
test Kevin''s patch. Thanks very much!

Best Regards, 
Xu Dongxiao 

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Tim Deegan
Sent: 2008年1月25日 18:01
To: Xu, Dongxiao
Cc: Tian, Kevin; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re: [PATCH][RFC]Provide fast write emulation
pathtorelease shadow lock

Hi,

At 09:41 +0800 on 25 Jan (1201254064), Xu, Dongxiao
wrote:
> But I found that even without Kevin''s patch, the guest would be
blue
> screen in Windows or print some call trace in Linux guest. Have you
> seen this issue before? Thanks!
Can you try building Xen with "vmxassist=y" on the make command-line?

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 09:32 +0800 on 30 Jan (1201685565), Xu, Dongxiao
wrote:
> Tim, could you tell me what''s the test case and test environment
> (changeset) when you take the stability test? Then I may use your
> environment to test Kevin''s patch. Thanks very much!
The 3.2 release (tagged version) should have passed some migration
stress testing; apparently the -unstable branch is not getting automatic
testing for this at the moment.  I''ll look at it manually.  Sorry about
that.

Can you tell me what the STOP codes were on the bluescreens that you
saw?

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Tim,

The stop code is: 
STOP: 0x0000000A (0xF94EAFFC, 0x000000FF, 0x00000001, 0x805434A2)

Best Regards,
Xu Dongxiao

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Tim Deegan
Sent: 2008年1月30日 17:46
To: Xu, Dongxiao
Cc: Tian, Kevin; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re: [PATCH][RFC]Provide fast write
emulationpathtorelease shadow lock

At 09:32 +0800 on 30 Jan (1201685565), Xu, Dongxiao
wrote:
> Tim, could you tell me what''s the test case and test environment
> (changeset) when you take the stability test? Then I may use your
> environment to test Kevin''s patch. Thanks very much!
The 3.2 release (tagged version) should have passed some migration
stress testing; apparently the -unstable branch is not getting automatic
testing for this at the moment.  I''ll look at it manually.  Sorry about
that.

Can you tell me what the STOP codes were on the bluescreens that you
saw?

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 21:07 +0800 on 30 Jan (1201727271), Xu, Dongxiao
wrote:
> Hi, Tim,
> 
> The stop code is: 
> STOP: 0x0000000A (0xF94EAFFC, 0x000000FF, 0x00000001, 0x805434A2)
I haven''t been able to reproduce this crash, but it certainly looks
like
the sort of thing a shadow bug would do.  Were you seeing this on a
particular version of Windows?

In the meantime, if you''re happy with the shadow lock patch, I think we
can take it into unstable. 

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Tim Deegan [mailto:Tim.Deegan@citrix.com] 
>Sent: 2008年2月12日 16:26
>
>At 21:07 +0800 on 30 Jan (1201727271), Xu, Dongxiao wrote:
>> Hi, Tim,
>> 
>> The stop code is: 
>> STOP: 0x0000000A (0xF94EAFFC, 0x000000FF, 0x00000001, 0x805434A2)
>
>I haven''t been able to reproduce this crash, but it certainly 
>looks like
>the sort of thing a shadow bug would do.  Were you seeing this on a
>particular version of Windows?
I think Dongxiao only tried one version of Windows. I''ll ask his help
to try
other versions after back from his vacation.
>
>In the meantime, if you''re happy with the shadow lock patch, I
think we
>can take it into unstable. 
That''d be great.

Thanks,
Kevn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

So, attached updated patch.

Thanks,
Kevin
>From: Tian, Kevin
>Sent: 2008年2月14日 9:54
>
>>From: Tim Deegan [mailto:Tim.Deegan@citrix.com] 
>>Sent: 2008年2月12日 16:26
>>
>>At 21:07 +0800 on 30 Jan (1201727271), Xu, Dongxiao wrote:
>>> Hi, Tim,
>>> 
>>> The stop code is: 
>>> STOP: 0x0000000A (0xF94EAFFC, 0x000000FF, 0x00000001, 0x805434A2)
>>
>>I haven''t been able to reproduce this crash, but it certainly 
>>looks like
>>the sort of thing a shadow bug would do.  Were you seeing this on a
>>particular version of Windows?
>
>I think Dongxiao only tried one version of Windows. I''ll ask 
>his help to try
>other versions after back from his vacation.
>
>>
>>In the meantime, if you''re happy with the shadow lock patch, 
>I think we
>>can take it into unstable. 
>
>That''d be great.
>
>Thanks,
>Kevn
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I''d like a final ack from Tim on this one before applying.

 -- Keir

On 15/2/08 06:06, "Tian, Kevin" <kevin.tian@intel.com> wrote:
> So, attached updated patch.
> 
> Thanks,
> Kevin
> 
>> From: Tian, Kevin
>> Sent: 2008年2月14日 9:54
>> 
>>> From: Tim Deegan [mailto:Tim.Deegan@citrix.com]
>>> Sent: 2008年2月12日 16:26
>>> 
>>> At 21:07 +0800 on 30 Jan (1201727271), Xu, Dongxiao wrote:
>>>> Hi, Tim,
>>>> 
>>>> The stop code is:
>>>> STOP: 0x0000000A (0xF94EAFFC, 0x000000FF, 0x00000001,
0x805434A2)
>>> 
>>> I haven''t been able to reproduce this crash, but it
certainly
>>> looks like
>>> the sort of thing a shadow bug would do.  Were you seeing this on a
>>> particular version of Windows?
>> 
>> I think Dongxiao only tried one version of Windows. I''ll ask
>> his help to try
>> other versions after back from his vacation.
>> 
>>> 
>>> In the meantime, if you''re happy with the shadow lock
patch,
>> I think we
>>> can take it into unstable.
>> 
>> That''d be great.
>> 
>> Thanks,
>> Kevn
>> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 10:01 +0000 on 15 Feb (1203069706), Keir Fraser
wrote:
> I''d like a final ack from Tim on this one before applying.
Ack.  

I read through again and the only thing I can see is a risk that on SMP
guests, a foreign vcpu might change the guest pagetable under our feet,
leading to a risk of using inconsistent mappings for reads and writes.
I think that''s OK, though, because
 - we already have similar exposure from vTLB &c, and will do from OOS;
 - a guest with good TLB flush discipline should be entirely safe.

Cheers,

Tim.
> On 15/2/08 06:06, "Tian, Kevin" <kevin.tian@intel.com>
wrote:
> 
> > So, attached updated patch.
> > 
> > Thanks,
> > Kevin
> > 
> >> From: Tian, Kevin
> >> Sent: 2008?$BG/2?$B7n14?$BF| 9:54
> >> 
> >>> From: Tim Deegan [mailto:Tim.Deegan@citrix.com]
> >>> Sent: 2008?$BG/2?$B7n12?$BF| 16:26
> >>> 
> >>> At 21:07 +0800 on 30 Jan (1201727271), Xu, Dongxiao wrote:
> >>>> Hi, Tim,
> >>>> 
> >>>> The stop code is:
> >>>> STOP: 0x0000000A (0xF94EAFFC, 0x000000FF, 0x00000001,
0x805434A2)
> >>> 
> >>> I haven''t been able to reproduce this crash, but it
certainly
> >>> looks like
> >>> the sort of thing a shadow bug would do.  Were you seeing this
on a
> >>> particular version of Windows?
> >> 
> >> I think Dongxiao only tried one version of Windows. I''ll
ask
> >> his help to try
> >> other versions after back from his vacation.
> >> 
> >>> 
> >>> In the meantime, if you''re happy with the shadow lock
patch,
> >> I think we
> >>> can take it into unstable.
> >> 
> >> That''d be great.
> >> 
> >> Thanks,
> >> Kevn
> >> 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Tim Deegan [mailto:Tim.Deegan@citrix.com] 
>Sent: 2008年2月15日 19:36
>
>At 10:01 +0000 on 15 Feb (1203069706), Keir Fraser wrote:
>> I''d like a final ack from Tim on this one before applying.
>
>Ack.  
>
>I read through again and the only thing I can see is a risk that on SMP
>guests, a foreign vcpu might change the guest pagetable under our feet,
>leading to a risk of using inconsistent mappings for reads and writes.
>I think that''s OK, though, because
> - we already have similar exposure from vTLB &c, and will do from OOS;
> - a guest with good TLB flush discipline should be entirely safe.
>
Yep. This is actually same as physical cpu behavior, as long as
inconsistent mappings are not stamped into shadow page table.

Thanks for comments,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel