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] [PATCH 0/6] PM extension to domU

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/6] PM extension to domU
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 7 Feb 2007 10:21:43 +0800
Delivery-date: Tue, 06 Feb 2007 18:21:30 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C1EEE280.8FB0%Keir.Fraser@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdJxpGp/qx+TgWOS6iQUGwbfBu5mQAcYarIAAczzZAAAZln5gAAG9xg
Thread-topic: [Xen-devel] [PATCH 0/6] PM extension to domU
>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