From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Scott Subject: Re: bug in hvmloader xenbus_shutdown logic Date: Thu, 5 Dec 2013 09:36:12 +0000 Message-ID: <52A0490C.9070804@eu.citrix.com> References: <0E6BCB61859D7F4EB9CAC75FC6EE6FF844B9280C@SZXEMA502-MBX.china.huawei.com> <1386150584.15530.7.camel@kazak.uk.xensource.com> <0E6BCB61859D7F4EB9CAC75FC6EE6FF844B937B6@SZXEMA502-MBX.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0E6BCB61859D7F4EB9CAC75FC6EE6FF844B937B6@SZXEMA502-MBX.china.huawei.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Liuqiming (John)" , Ian Campbell Cc: Yanqiangjun , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 05/12/13 02:08, Liuqiming (John) wrote: > According to oxenstored source code, oxenstored will read every domain's IO ring no matter what events happened. > > Here is the main loop of oxenstored: > > let main_loop () = ... > process_domains store cons domains <- no matter what event income, this will handle IO ring request of all domains > in > > so when one domain's hvmloader is clearing its IO ring, oxenstored may access this IO ring because of another domain's event happened. Yes, this version of the code checks all the interdomain rings every time it goes around the main loop. FWIW my experimental updated oxenstore uses one (user-level) thread per connection. I had thought this was just an efficiency issue... I didn't realise it had correctness implications. >> On Wed, 2013-12-04 at 04:25 +0000, Liuqiming (John) wrote: >> >>> memset can not set all the page to zero in an atomic way, and during >>> the clear up process oxenstored may access this ring. >> >> Why is oxenstored poking at the ring? Surely it should only do so when >> the guest (hvmloader) sends it a request. If hvmloader is clearing the >> page while there is a request/event outstanding then this is an >> hvmloader bug. Ok, that makes sense. My only hesitation is that violations of this rule (like with current oxenstored) show up rarely. Presumably the xenstore ring desynchronises and the guest will never be able to boot properly with PV drivers. I don't think I've ever seen this myself. Do frontends expect the xenstore ring to be in a zeroed state when they startup? Assuming hvmloader has received all the outstanding request/events, would it be safe to leave the ring contents alone? Cheers, Dave