RE: [Xen-devel] [PATCH 0/6] PM extension to domU

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年2月7日 9:57
>> Sorry that I don't quite understand you. For suspend-to-disk, maybe
>> we can use that policy to recreate driver domains. But for
>> suspend-to-ram, that process is still slow and we just need suspend
>> domain itself. Also I'm not sure why it's stateless... How do you
>> recover workloads after re-creation?
>
>A proper driver domain would be little more than a device driver wrapped
>in
>minios-style Xen-interfacing code. They should be quick to start, and
>restart would lose no workload. I suppose there are people running
>device
>drivers as part of a full guest however...

So this is the point about definition about driver domains. If we 
consider driver domain as the part of I/O virtualization service 
provider like dom0, minios-style is perfectly right and quick. 
However we have to consider the cases where user just wants 
device passthrough for performance. Actually most requirements 
on the list before driver domain was back to xen3.0, are all related 
to a full guest which doesn't provide backend service to others.

Then actually we have two scenarios:
        - Minios-driver domains created automatically to balance I/O 
virtualization, as part of increasing overall xen performance
        - Full guest with direct device assignment just for performance, 
which is created by user manually

I think we need cover both cases.

>
>Is it necessary to sleep/wake non driver domains? Could we check in S3
>support that would work for systems with all drivers in dom0, and then
>consider this patchset as an extension?
>
> -- Keir

It's still necessary to sleep/wake non driver domains, or else simple 
pause/unpause out of domain's knowledge is not enough. For example, 
at least time_resume is necessary after a long sleep/wake period. 

If you prefer to check in basic S3 first, OK I can hold it after that. 
Currently I sent out this patch set because it's self-contained. Anyway, 
we're doing final cleanup and rebase for S3, and should be able to 
send out soon.

Thanks,
Kevin

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