[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel][PATCH] handle ld.s on guest tr mapped page.


  • To: "Alex Williamson" <alex.williamson@xxxxxx>
  • From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • Date: Wed, 16 Aug 2006 19:41:36 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 16 Aug 2006 04:42:03 -0700
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcbAjZCnqeYLE4p8TmC4/PduKIjuTAAmWjkg
  • Thread-topic: [Xen-ia64-devel][PATCH] handle ld.s on guest tr mapped page.

Hi Alex,

Thanks for your comments,
This new patch preserves non-VTI domains dcr state.

Dcr of non-VTI domains is invariable, that's OK if non-VTI domain is linux,
But for other non-VTI domain (if we have), it may not be correct.

>From my understanding, only dcr.dm and dcr.pp need to be virtualized.
Currently XEN/IPF doesn't support dcr.be=1 mode and XEN/IPF can't support
32bit application.
So dcr.be and dcr.lc don't need to be virtualized.

>we'll end up "leaking" cr.dcr state out to everyone else.  How much will
>adding cr.dcr to the domain state affect performance?
I didn't get performance data about this, and I don't feel any explicit 
performance degradation. For correctness, we must set dcr.dm=0, future tunning 
is definitely needed.

Thanks,
Anthony


>Hi Anthony,
>
>   I don't see where non-VTI domains get switched back to a default dcr
>value.  Did I miss it?  Seems like this only covers the VTI domains and
>we'll end up "leaking" cr.dcr state out to everyone else.  How much will
>adding cr.dcr to the domain state affect performance?  Thanks,
>
>       Alex
>
>--
>Alex Williamson                             HP Open Source & Linux Org.

Attachment: lds_ontrpage2.patch
Description: lds_ontrpage2.patch

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.