Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965891AbdCXOlJ (ORCPT ); Fri, 24 Mar 2017 10:41:09 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60461 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965855AbdCXOlB (ORCPT ); Fri, 24 Mar 2017 10:41:01 -0400 Date: Fri, 24 Mar 2017 15:40:51 +0100 From: Cornelia Huck To: Marcelo Tosatti Cc: Dmitry Vyukov , David Hildenbrand , KVM list , Paolo Bonzini , Radim =?UTF-8?B?S3LEjW3DocWZ?= , stable , LKML Subject: Re: [PATCH v2] KVM: kvm_io_bus_unregister_dev() should never fail In-Reply-To: <20170324103257.GA5250@amt.cnet> References: <20170323172419.21435-1-david@redhat.com> <20170323204247.GC27861@amt.cnet> <20170324103257.GA5250@amt.cnet> Organization: IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz =?UTF-8?B?R2VzY2jDpGZ0c2bDvGhydW5nOg==?= Dirk Wittkopp Sitz der Gesellschaft: =?UTF-8?B?QsO2Ymxpbmdlbg==?= Registergericht: Amtsgericht Stuttgart, HRB 243294 X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17032414-0008-0000-0000-0000040DFB21 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17032414-0009-0000-0000-00001CF7CCB9 Message-Id: <20170324154051.5398a703.cornelia.huck@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-24_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703240127 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 670 Lines: 16 On Fri, 24 Mar 2017 07:33:01 -0300 Marcelo Tosatti wrote: > Still dislike the "unregister all bus devices" as that renders the guest > unuseable. Can't you fail gracefully? Say force qemu error. The callers are probably too varied to find a common way to do that (multiply with different user space tools). At least for some cases, the guest will be terminated in the near future anyway: For example, on s390 a NULL bus will cause an error to be propagated through KVM_RUN on the next guest->host virtio notification, which will cause qemu to terminate the guest. This situation is not ideal, but this is probably the most reasonable approach.