| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] FE driver and log dirty
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: 2008年7月14日 15:28
>
>On 14/7/08 08:18, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> **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?
>
>Not sure what you mean? There can be requests which the FE
>re-queues after
>resume which have in fact already been satisfied (pre-suspend)
>and even the
>response queued up in the old shared request/response ring.
>The key is that
>replaying them is idempotent.
>
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...
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home