WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] FE driver and log dirty

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] FE driver and log dirty
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 14 Jul 2008 10:14:31 +0100
Cc:
Delivery-date: Mon, 14 Jul 2008 02:14:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D955F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjlgcleH6AfAfjWTPSrkcaRDBcgVgAAVJukAAAXLwAAA6NjYA==
Thread-topic: [Xen-devel] FE driver and log dirty
User-agent: Microsoft-Entourage/11.4.0.080122
On 14/7/08 08:39, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> I can understand the replay trick here. My question is whether there're
> some requests/responses got dequeued from FE driver and already
> sent to up level component, which however has not been ever accessed
> by CPU (e.g. only descriptor is accessed) before __xen_suspend is
> entered. Take network receive for example (I'm not familar with this
> path), is it possible that some data page is already queued in up level
> protocol, and then suspend watch is triggered before receive process
> is scheduled, and unfortunately within that window the page has not
> been accessed yet? In this case, page becomes dirty in live migration
> process, but not get recoded by log dirty logic since it's only BE to
> access it...

Granted mappings cause the mapped page to become dirtied when the BE
relinquishes the grant. This happens after the I/O transfer but before the
response has been queued for the FE.

 -- Keir



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

<Prev in Thread] Current Thread [Next in Thread>