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

[Xen-devel] FE driver and log dirty


  • To: "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Mon, 14 Jul 2008 15:18:17 +0800
  • Delivery-date: Mon, 14 Jul 2008 00:18:56 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcjlgcleH6AfAfjWTPSrkcaRDBcgVg==
  • Thread-topic: FE driver and log dirty

Here's a question about FE driver and log dirty, when live migration
is concerned. Log dirty mode is used in live migration, which works
for those polluted pages from CPU issued accesses, but not for
DMA path (as BE driver talked here which access from another
domain like dom0). Most frontend drivers don't implement their
own suspend interface (netfront implements when accelerator is 
enabled). That seems to make sense, e.g. blkfront shadows pending
reqs, and requeue them after resume. However considering log dirty
mode, there's an assumption for this style:

**There must be some CPU issued accesses to target data page
before xen_suspend is invoked, if that page is serviced by BE driver 
and has been dequeued from FE queues within the loop copy 
process. Or else log dirty mode is not triggered to re-transimit that
page in next loop. **

Does that assumption always hold true for existing FE drivers?

Thanks,
Kevin

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


 


Rackspace

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