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] Re: Rename all dying domains to be prefixed with Zombie.

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Rename all dying domains to be prefixed with Zombie. This allows a new domain
From: harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 06 Oct 2005 18:37:28 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ewan Mellor <ewan@xxxxxxxxxxxxx>
Delivery-date: Thu, 06 Oct 2005 17:34:48 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43453F51.3050001@xxxxxxxxxx>
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>
References: <E1ENSnM-0002c4-RB@xxxxxxxxxxxxxxxxxxxxx> <20051006134723.GC19844@xxxxxxxxxxxxxxxxxxx> <20051006135747.GB21233@xxxxxxxxxxxxxxxx> <43453F51.3050001@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
IIUC, in the case you describe below, the data is good data from the old
domain instance (the shared pages pinned by the BE still contain the
data the FE intended right?), the only problem is if it gets written
after the new domain instance performs a read or write to an overlapping
extent.

I think this requires some kind of equivalent of "clear task set" to
ensure that all IO from the old domain instance is killed before the new
domain instance starts doing any.

There's a different case where you unload a driver and want to free up
the shared page.  It's necessary to make sure that the BE stops looking
at the shared page before the FE frees it for a different purpose.

This second case is also subtle because the way the rings work means
that even if there is no IO outstanding in the BE it is still possible
that there is an interrupt pending in the BE to look at the ring.  If
the ring is freed up whilst there is an interrupt pending then the
interrupt may see ring contents which cause a spurious write.

This second case requires an explicit handshake with the BE to unload a
driver module.

Harry.

On Thu, 2005-10-06 at 10:14 -0500, Anthony Liguori wrote:
> Ewan Mellor wrote:
> 
> >On Thu, Oct 06, 2005 at 09:47:23AM -0400, Sean Dague wrote:
> >  
> >
> >If a domain has been destroyed, even if it's a zombie in the dying state, it
> >will never execute another instruction.  Xen may be unable to clean up after
> >it, but you are guaranteed that it won't write to the filesystem any longer.
> >  
> >
> It doesn't need to.  There's no guarentee that the backend has flushed 
> all of the data in the write queue until after the domain has been 
> destroyed.
> 
> You could potentially have a domain read from a block device and then 
> the dying domain flush some changes to the disk and end up with a 
> corrupted disk.
> 
> Regards,
> 
> Anthony Liguori
> 
> >Ewan.
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-devel
> >
> >  
> >
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 


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